Using  Architectures 
For  Research,  Development, 
and  Aequisition 


C.E.  Dickerson 
S.M.  Soules 
M.R.  Sabins 
P.H.  Charles 


Approved  for  public  release;  distribution  is  unlimited. 


Report  Documentation  Page 

Form  Approved 

0MB  No.  0704-0188 

Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 

VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  0MB  control  number. 

1.  REPORT  DATE 

07  OCT  2004 

2.  REPORT  TYPE 

N/A 

3.  DATES  COVERED 

4.  TITLE  AND  SUBTITLE 

Using  Architectures  for  Research,  Development,  and  Acquisition 

5a.  CONTRACT  NUMBER 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

6.  AUTHOR(S) 

5d.  PROJECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

BAE  Systes,  11487  Sunset  Hills  Rd.,  Reston,  VA  20190 

8.  PEREORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

10.  SPONSOR/MONITOR’S  ACRONYM(S) 

11.  SPONSOR/MONITOR’S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release,  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

The  original  document  contains  color  images. 

14.  ABSTRACT 

15.  SUBJECT  TERMS 

16.  SECURITY  CLASSIEICATION  OE: 

17.  LIMITATION  OE 
ABSTRACT 

uu 

18.  NUMBER 
OE  PAGES 

194 

19a.  NAME  OE 
RESPONSIBLE  PERSON 

a.  REPORT 

unclassified 

b.  ABSTRACT 

unclassified 

c.  THIS  PAGE 

unclassified 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


Using  Architectures  for  Research,  Development,  and  Acquisition 


PREFACE 

As  the  Department  of  Defense  (DoD)  moves  steadily  toward  increasingly  complex  weapon 
systems  that  rely  on  information  technology  for  joint  operation,  the  need  for  interoperation  of 
systems  becomes  more  critical  to  the  achievement  of  military  capabilities.  It  also  demands  new 
methods  for  the  acquisition  of  systems  and  the  assemblage  of  battle  forces.  We  can  no  longer 
afford  the  cost,  either  material  or  human,  associated  with  acquiring  individual  systems  without 
considering  how  the  interoperation  of  these  systems  affects  the  capability  of  the  Battleforce. 

When  the  DoD  introduced  the  Command,  Control,  Communications,  Computers,  Intelligence, 
Surveillance,  and  Reconnaissance  (C4ISR)  Architecture  Framework  in  1996,  its  intention  was  to 
provide  the  DoD  community  with  a  standard  method  for  expressing  the  complex  information 
exchange  relationships  that  reflected  the  best  systems  engineering  practices  of  government  and 
industry.  Since  then,  many  advances  have  been  made  in  DoD  acquisition  practices,  the  most 
significant  of  which  has  been  the  recent  focus  on  capabilities-based  acquisition.  The  idea  of 
organizing  the  acquisition  strategy  around  specific  military  capabilities  delivered  by  a  Family  of 
Systems  (FoS)  is  traceable  to  reforms  in  the  British  Ministry  of  Defense  in  the  late  1990s.  These 
reforms  were  a  significant  departure  from  the  traditional  practice  of  organizing  the  acquisition 
strategy  around  specific  threats  to  be  countered  by  individual  systems,  platforms,  or  military 
components.  The  revolutionary  FoS  concept  is  being  explored  today  at  the  highest  levels  of  the 
DoD  and  across  the  individual  Services. 

The  goal  of  this  book  is  to  show  how  architectures  can  be  used  to  enable  a  capabilities-based 
approach  to  the  research,  development,  and  acquisition  of  DoD  families  of  systems  that  must 
interoperate  with  each  other  in  the  conduct  of  military  operations.  Much  has  been  written  about 
architectures  and  about  capabilities-based  acquisition.  This  book  is  about  the  pilot  projects  that 
have  actually  been  used  to  explore  the  utility  of  the  architecture  methodology  for  both  U.S.  Navy 
fleet  experimentation  and  the  recent  building  of  the  Fiscal  Year  2004  Program  Objective 
Memorandum  (POM  04)  acquisition  plan.  At  the  time  of  this  book’s  publication,  the  architecture 
methodology  has  been  used  successfully  to  describe  and  assess  components  of  two  Fleet  Battle 
Experiments.  It  was  also  used  to  develop  organizing  exhibits  at  the  early  stages  of  planning  for 
POM  04,  although  the  exhibits  were  not  used  in  the  final  decision-making  process.  The  Assistant 
Secretary  for  the  Navy  (ASN)  Research,  Development,  and  Acquisition  (RDA)  Chief  Engineer 
did  use  the  Multi-Attribute  Utility  Analysis  to  advise  ASN(RDA).  Additionally,  the  architecture 
methodology  has  been  used  to  influence  decision-making  with  U.S.  Coalition  partners. 

In  order  to  use  the  architecture  methodology  to  support  these  efforts,  it  was  necessary  to  adapt 
the  Framework’s  best  practices  for  architecting  complex  information  exchange  relationships  to  a 
systems  engineering  process  that  addressed  complex  families  of  systems.  It  was  critical  to 
provide  a  much  greater  degree  of  integration  between  these  practices  and  the  military  concept  of 
operations  to  yield  systems  and  weapons  that  could  deliver  required  capabilities.  The 
implications  of  this  kind  of  integration  are  clearly  illustrated  by  the  Coalition  Forces’  integration 
of  C4ISR  and  precision  guided  munitions  used  in  military  operations  in  Afghanistan  and  more 
recently  in  Iraq  to  achieve  new  time-sensitive  targeting  capabilities  against  unusual  and 
asymmetric  threats.  This  improved  integration  of  information  and  weapon  systems  has  allowed 
engagement  of  threats  at  ranges  that  maximize  weapon  effectiveness  while  minimizing  casualties 
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to  our  own  forces  as  well  as  collateral  damage  to  noncombatants.  Ultimately,  the  increased 
integration  of  C4ISR  and  information  technology  with  weapon  systems  should  result  in  a  new 
generation  of  warfare,  which  is  widely  referred  to  as  Network  Centric  Warfare. 

There  has  been  substantial  advocacy  at  the  Office  of  the  Secretary  of  Defense  (OSD)  level  for 
the  use  of  architectures  in  capabilities-based  acquisition.  Proponents  include  Mr.  John 
Osterholtz,  Director  of  Architecture  and  Interoperability  for  the  DoD  Chief  Information  Officer, 
and  Dr.  V.  Garber,  Director  of  Systems  Integration,  Office  of  the  Undersecretary  of  Defense 
(OUSD)  for  Acquisition,  Technology,  and  Logistics  (AT&L).  Both  of  these  individuals  have 
provided  leadership  across  the  information  technology  and  system  acquisition  communities.  Mr. 
Truman  Parmele,  Command  Information  Superiority  Architectures  (CISA)  Program  Manager  for 
the  Office  of  the  Assistant  Secretary  of  Defense  (OASD)/Network  Integration  and 
Interoperability  (Nil),  has  led  the  development  of  the  C4ISR  Architecture  Framework  during  its 
evolution  over  the  past  several  years  and  is  responsible  for  inclusion  of  this  book  into  the  current 
desktop  series. 

Development  of  the  methodologies  presented  in  this  book  and  pursuit  of  the  pilot  projects  (case 
studies)  that  provide  proof  of  concept  have  been  supported  by  the  ASN(RDA)  and  the  Assistant 
Secretary’s  Office  of  the  Chief  Engineer.  The  work  was  begun  under  the  Honorable  Dr.  Lee 
Buchanan  and  the  first  Chief  Engineer,  Rear  Admiral  Kathleen  Paige.  It  was  finished  under  the 
Honorable  Mr.  John  Young  and  the  subsequent  Chief  Engineers,  Rear  Admirals  Michael  Mathis 
and  Michael  Sharp.  The  principal  deputy  for  the  Assistant  Secretary,  Mr.  Paul  Schneider,  was 
also  instrumental  in  the  success  of  this  work.  CAPT  Dennis  Sorensen  of  the  Naval  Air  Station, 
Patuxent  River,  was  instrumental  in  both  the  overall  technical  review  of  this  book  and  the 
development  of  the  Precision  Engagement  example  in  the  case  studies. 

Ms.  Jacqueline  Owens  Lancaster  of  BAE  Systems  and  previously  of  ManTech  Systems 
Engineering  Corporation  is  the  editor  of  this  work.  It  is  to  her  credit  that  the  technical  material  in 
this  book  is  written  in  a  manner  intended  to  be  understandable  to  all  who  read  it.  Most  of  the 
graphics  in  the  book  have  been  created  over  the  last  three  years  by  Mr.  Darrold  Johnson  of 
Strategic  Insight  and  Ms.  Davina  Marklin  of  BAE  Systems.  The  quality  of  their  work  speaks  for 
itself  Special  thanks  must  also  go  to  Ms.  Cynthia  Smith  of  BAE  Systems,  who  was  my 
administrative  assistant  during  my  tenure  in  the  Chief  Engineer’s  office.  Her  support  in 
compiling  the  editorial  and  graphic  content  of  the  book  helped  us  all. 

This  book  provides  the  early  artifacts  of  an  architecture-based  systems  engineering  approach  to 
the  research,  development,  and  acquisition  of  DoD  systems.  We  hope  that  it  will  provide  the 
DoD  community  with  new  insights  into  capabilities-based  acquisition  that  will  help  the 
community  chart  the  course  for  new  capabilities  like  those  promised  by  Network  Centric 
Warfare. 


C.  E.  Dickerson 
Director  of  Architecture 
Office  of  the  Chief  Engineer 

Assistant  Secretary  of  the  Navy  for  Research,  Development  and  Acquisition 
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PARTI 

INTRODUCTION 

This  part  of  the  book  introduces  the  challenge  the  Department  of  Defense  (DoD)  faces  in 
attempting  to  move  toward  a  Research,  Development,  and  Acquisition  (RDA)  strategy  that 
focuses  on  achievement  of  capabilities  through  a  Family  of  Systems  (FoS)  systems  engineering 
approach.  While  this  change  in  approach  represents  a  significant  and  critical  departure  from  the 
way  DoD  has  done  business  in  the  past,  it  is  widely  recognized  that  this  approach  is  the  best 
possible  method  for  achieving  real  and  measurable  improvement  in  defense  capabilities.  The 
DoD  has  decided  to  use  the  FoS  approach  in  pursuing  the  military  advantages  made  possible 
through  the  concepts  of  Network  Centric  Warfare  (NCW).  The  Army,  Navy,  Air  Force,  Marine 
Corps,  National  Security  Agency/Central  Security  Office,  Missile  Defense  Agency,  National 
Imagery  and  Mapping  Agency,  and  Defense  Threat  Reduction  Agency  have  all  adopted  visions 
for  NCW,  and  it  is  clear  that  all  DoD  elements  recognize  the  importance  of  NCW  capabilities  to 
the  achievement  of  Battlespace  dominance.  What  remains  unknown  to  many  DoD  agencies  is 
how  to  move  from  acknowledgement  that  capability-based  acquisition  through  an  FoS  systems 
engineering  approach  is  needed  to  achieve  NCW  to  an  actual  implementation  approach.  This  part 
of  the  book  lays  the  groundwork  for  understanding  how  an  architecture-based  process  can 
provide  the  framework  necessary  to  integrate  capabilities  across  FoSs  in  order  to  achieve  new 
capabilities,  including  NCW.  The  next  part  of  the  book  builds  upon  this  foundation  by  providing 
case  studies  that  illustrate  how  the  Architecture  Framework  products  have  actually  been  used. 
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CHAPTER  1 

MOVING  TOWARD  ARCHITECTURE-BASED  SYSTEMS  ENGINEERING 
Purpose 

DoD  currently  faces  a  critical  challenge:  it  must  integrate  multiple  capabilities  across  both 
developing  systems  and  often  disparate  legacy  systems  that  support  multiple  warfare  areas.  To 
meet  this  challenge,  DoD  has  been  reorganizing  in  order  to  integrate  acquisition  activities  in  a 
way  that  leads  to  the  achievement  of  capabilities  through  FoSs  rather  than  just  individual  systems 
or  platforms.  The  modification  of  the  engineering  methods  needed  to  support  capabilities-based 
acquisition  uses  architectures  as  the  key  element  in  the  new  methodology.  This  chapter 
establishes  a  framework  within  which  architectures  are  being  used  for  capabilities-based 
research,  development,  and  acquisition  within  DoD.  It  focuses  specifically  on  NCW  as  an  area 
where  the  requirement  for  ever-increasing  levels  of  interoperability  can  be  met  through  the  use  of 
an  architectural  approach  for  acquiring  the  FoSs  necessary  to  support  this  critical  capability.  Part  II 
of  the  book  builds  on  this  introduction  by  providing  five  case  studies  that  clearly  illustrate  how 
the  architectural  methodology  is  applied  to  the  FoS  systems  engineering  process. 

The  Distinction  Between  FoS  Concepts  and  Classical  Systems  Engineering 

Architects  play  a  key  role  in  FoS  engineering.  Classical  systems  engineering^  focuses  on 
designing  a  best  solution  (system)  for  a  bounded,  controlled  problem.  But  the  FoS  systems 
engineering  process  is  intended  to  enable  the  acquisition  of  capabilities  from  both  the  individual 
operation  and  the  collective  interoperation  of  the  systems  that  comprise  the  FoS.  Therefore,  the 
FoS  architects,  unlike  classical  systems  engineers,  will  not  have  control  of  many  of  the  design 
parameters  associated  with  the  FoS.  For  example,  in  the  assemblage  of  a  Battleforce,  80  to  90 
percent  of  the  systems  may  be  legacy  systems  over  which  the  architect  has  no  control.  The 
critical  distinction  of  FoS  engineering  is  its  focus  on  the  capabilities  attainable  from  the 
assemblage  of  systems  rather  than  from  a  single  system  design,  and  it  is  this  distinction  that 
drives  the  architectural  methods  for  FoS  acquisition. 

It  should  be  obvious,  then,  that  architects  play  a  key  role  in  FoS  engineering.  The  FoS  architect 
provides  a  critical  link  between  the  warfighter  and  the  systems  engineer.  The  architect  captures 
the  warfighter’s  requirements  and  transforms  them  into  a  language  that  can  be  understood  by  the 
systems  engineer.  Additionally,  the  architect  must  have  a  firm  understanding  of  what  the 
warfighter  requires  today  and  how  the  future  may  alter  those  needs.  He  or  she  must  be  able  to 
interpret  both  current  and  future  needs  and  lay  out  a  preliminary  sketch  of  an  FoS  that  will 
accomplish  the  warfighter’s  requirements  while  remaining  responsive  to  change.  The  architect 
must  then  work  with  the  system  engineer  to  determine  the  most  operationally  sound,  technically 
feasible,  and  cost  effective  program  investments.  Reaching  an  acceptable  balance  among 
warfighter  needs,  ability  to  build  systems  that  meet  those  needs,  future  flexibility,  and  cost 
should  be  in  the  domain  of  the  FoS  architect. 


^  For  the  purposes  of  this  book,  the  systems  engineering  methods  and  standards  like  IEEE  1220  that  have  been 
historically  used  to  design  individual  systems  or  platforms  will  be  referred  to  as  “classical  systems  engineering.” 
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DoD  Responses  to  the  Challenge 

The  most  exciting  opportunity  for  which  the  U.S.  DoD  has  chosen  to  achieve  FoS  capabilities  is 
NCW,  which  is  executed  through  Network  Centric  Operations  (NCO).  NCW  is  a  collection  of 
warfighting  concepts  that  lead  to  military  capabilities  with  which  warfighters  take  advantage  of 
all  available  information  and  bring  all  available  assets  to  bear  in  a  rapid  and  flexible  manner. 
NCW  includes  the  following  basic  tenets: 

•  A  robustly  networked  force  to  improve  information  sharing 

•  Information  sharing  to  enhance  the  quality  of  information 

•  Shared  situational  awareness  to  enable  collaboration  and  self-synchronization  and  to  enhance 
the  sustainability  and  speed  of  command 

•  A  dramatic  increase  in  mission  effectiveness  enabled  through  the  first  three  tenets^ 

The  Army,  Navy,  Air  Force,  Marine  Corps,  National  Security  Agency/Central  Security  Office, 
Ballistic  Missile  Defense  Office,  National  Imagery  and  Mapping  Agency,  and  Defense  Threat 
Reduction  Agency  have  all  adopted  visions  and  implementation  plans  for  NCW.  The  NCW 
strategies  for  four  of  these  agencies  are  outlined  in  the  following  paragraphs. 

In  detailing  its  NCW  vision,  the  Army  provided  a  conceptual  template  for  its  transformation  into 
a  force  that  is  strategically  responsive  and  dominant  across  the  full  spectrum  of  operations  and  an 
integral  member  of  the  Joint  warfighting  team.  The  Army  has  stated  that  accomplishing  its  vision 
is  strongly  dependent  on  the  potential  of  linking  together  networking,  geographically  dispersed 
combat  elements.  In  doing  so,  the  Army  expects  to  achieve  significant  improvements  to  shared 
Battlespace  understanding  and  increased  combat  effectiveness  through  synchronized  actions.  The 
theory  behind  the  Army’s  NCW  vision  is  that  by  linking  sensor  networks.  Command  and  Control 
(C^)  networks,  and  shooter  networks,  it  can  achieve  efficiencies  in  all  military  operations  from 
the  synergy  that  would  be  derived  by  simultaneously  sharing  information  in  a  common  operating 
environment.  In  addition,  such  linkages  allow  for  the  discovery  of  new  concepts  of  operations 
both  among  Army  forces  and  Joint  forces  in  theater.^ 

The  Navy’s  “Network  Centric  Operations  (NCO),  A  Capstone  Concept  for  Naval  Operations  in 
the  Information  Age”  articulates  the  Navy's  path  to  NCW.  This  document  states  that,  “In 
developing  NCW  systems,  a  different  approach  to  applying  the  principles  must  be  taken.  NCW 
requires  that  technology,  tactics,  and  systems  be  developed  together.”  The  Navy  document  also 
points  to  three  military  trends:  a  shift  toward  Joint,  effects-based  combat;  heightened  reliance  on 
knowledge  superiority;  and  use  of  technology  by  adversaries  to  rapidly  improve  capabilities  in 
countering  U.S.  strengths.  It  notes  that  these  trends  underline  the  necessity  for  coordinated  NCW 
that  enables  substantial  gains  in  combat  power  through  the  joining  of  networking  and 
information  technology  with  effects-based  operations.  “The  power,  survivability  and  effectiveness 
of  the  future  force  will  be  significantly  enhanced  through  networking  of  warfighters.”^ 

The  Air  Force’s  NCW  vision  recognizes  that  dominating  the  information  spectrum  is  just  as 
critical  to  conflict  today  as  controlling  air  and  space  or  occupying  land  was  in  the  past.  This 
vision  document  notes  that  the  time  available  for  collecting  information,  processing  it  into 
knowledge,  and  using  it  to  support  warfighting  initiatives  is  shrinking.  It  also  acknowledges  that 
while  possessing,  exploiting,  and  manipulating  information  have  always  been  essential  parts  of 
warfare,  information  has  evolved  beyond  its  traditional  role.  “Today,  information  is  itself  both  a 
weapon  and  a  target.”  The  Air  Force  vision  states  that  improved  capabilities  will  be  needed  to 
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deal  with  the  increasing  volume  of  information,  emerging  threats,  and  the  challenges  of 
tomorrow.  It  also  states  that  the  key  to  improving  Air  Force  capabilities  involves  not  just 
improvements  to  individual  sensors,  networking  sensors,  and  improved  C2  for  sensors,  but  also 
in  new  ways  of  thinking  about  warfare  and  the  integration  of  U.S.  forces.'* * 

While  the  Marine  Corps  has  not  historically  used  the  term  Network  Centric  Warfare,  the  Corps 
notes  in  its  vision  document  that  the  principles  embodied  by  the  term  have  been  an  integral  part 
of  Marine  Corps  operations  for  years.  The  Corps  acknowledges  that  their  continued  capability  to 
meet  these  challenges  will  be  its  ability  to  capitalize  on  and  expand  its  networked  command  and 
control  structure  to  train  and  educate  the  future  force  in  effects  sensitive  decision-making.^ 

Clearly,  the  concept  of  NCW  has  been  embraced  by  all  the  services,  and  it  is  apparent  that 
realizing  the  Services’  individual  visions  of  NCW  will  inherently  require  ever-increasing  levels 
of  interoperability.  Accordingly,  NCW  is  an  ideal  capability  example  for  illustrating  how 
architectural  methods  can  be  used  to  support  the  FoS  systems  engineering  approach  necessary 
for  capability-based  acquisition. 

An  Illustration  of  the  Concept  of  FoS  Capabilities 

How  will  U.S.  military  forces  be  assembled  and  how  will  they  interoperate  to  achieve  new 
capabilities  through  the  principles  of  NCW?  The  answer  to  this  question  may  be  found  through 
understanding  the  interplay  between  military  operations  and  military  systems  caused  by 
advances  in  technology.  Lessons  learned  from  the  German  Blitzkrieg  of  World  War  II  provide 
some  insights.  Blitzkrieg  was  an  offensive  revolution  based  on  weapon  technology  and 
communications  capabilities  —  and  the  command  structures  designed  to  exploit  both 
simultaneously.  All  three  elements  were  essential  to  the  success  of  this  battlefield  tactic.  But  the 
lynchpin  of  the  new  tactic  was  the  radio.  Radios  had  been  available  to  the  military  in  World  War 
I,  but  they  were  bulky  due  to  power  supply  limitations.  By  the  time  of  World  War  II,  early 
efforts  at  miniaturization  (a  word  that  would  echo  throughout  the  world  for  years  to  come  and 
both  drive  and  allow  giant  leaps  forward  in  all  forms  of  commerce)  had  reduced  power  demands, 
allowing  reliable  radios  to  be  installed  in  both  tanks  and  aircraft.  Portable  radio  sets  were 
provided  as  far  down  in  the  military  echelons  as  the  platoon.  In  every  tank  there  was  at  least  one 
radio.  Advances  in  communications  and  information  technologies  in  the  1980s  and  1990s  will 
enable  NCW  in  ways  that  are  similar  to  the  marmer  in  which  the  radio  and  advances  in  weapons 
technology  enabled  Blitzkrieg.^ 

NCW  is  more  about  the  capabilities  achieved  through  the  interoperation  of  systems  than  it  is 
about  networks.  The  networks  simply  enable  the  interoperation.^  Figure  1-1  illustrates  the 
conceptual  shift  from  a  platform-centric  system  architecture  to  a  network  centric  system 
architecture.  Platform  centric  operations  usually  involve  a  sectored  Battlespace  as  a  means  to 
control  weapon  systems  and  engagements.  Platforms  carry  sensors,  processors,  and  weapons  (or 
combinations),  the  effectiveness  of  which  can  be  increased  dramatically  by  FoS  integration 
enabled  by  a  network  centric  architecture.  Figure  1-1  is  an  example  of  the  third  key  concept^  of 

^  The  following  bullets  describe  the  three  key  concepts: 

•  The  use  of  geographically  dispersed  forces 

•  The  empowerment  of  forces  by  knowledge  superiority 

•  The  effective  linkage  of  dispersed  and  distributed  entities  in  the  Battlespace 
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NCW  cited  by  Alberts  and  Gartska  ,  namely  the  effeetive  linking  of  dispersed  and  distributed 
entities  in  the  Battlespace.  The  importance  of  real-time  fusing  of  multiple  sensor  outputs  as  a 
driver  for  the  target  engagement  architecture  cannot  be  overemphasized;  it  is  fundamental  to 
bringing  network-centric  operations  to  the  point  where  U.S.  forces  meet  the  enemy.  This  change 
in  architeeture  brought  about  by  linked  sensors  is  also  illustrated  in  Figure  1-1.^ 


The  implieations  for  change  in  the  nature  of  eombat  engagement  as  illustrated  in  Figure  1-1  are 
profound.  On  a  single  platform,  it  is  relatively  easy  to  close  the  observe,  orient,  decide,  and  act 
(OODA)  loop.  The  challenge  in  network-centric  operations  is  to  enable  OODA  loops  that  span 
spaee  and  time  as  effeetively  and  as  rapidly  for  dispersed  force  elements  as  for  a  single  platform, 
partieularly  when  some  sensors  may  be  involved  in  multiple  loops.  Any  sensor  and  processor 
with  useful  data  or  information  will  provide  it  for  anyone  who  can  use  it,  and  the  provider  may 
not  know  who  the  user  is  nor  the  user  who  the  provider  is.  In  a  larger  context,  however,  the 
operation  of  the  network  will  remain  a  closed  loop  in  that  the  information  will  lead  to  aetion,  and 
the  mission  decision  maker  -  the  one  who  decides  what  the  target  is  -  will  have  to  know  that  the 
target  was  engaged  and  the  outcome  of  that  engagement  as  conditions  for  deciding  on  further 
action. 
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Adapted  from:  Network-Centric  Naval  Forces,  Naval  Studies  Board,  National  Research  Council,  Figure  1.5,  Page  27 
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Figure  1-1.  FoS  Integration  through  Networks 


The  simple  eonstruct  illustrated  in  Figure  1-1  can  be  applied  broadly  to  many  military  FoS 
examples.  In  Figure  1-2,  networks  enable  the  sensors  and  weapons  to  be  located  on  different 
platforms,  as  indicated  by  the  color  coding  in  the  graphic.  Thus,  unarmed  Guardrail  aircraft  are 
able  to  perform  part  of  the  targeting  funetions  using  the  eommon  data  link  (CDL)  to  pass 
targeting  data  for  use  hy  the  Advaneed  Taetical  Missile  System  (ATACMS),  which  performs 
engagement  functions. 
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Figure  1-2.  Example  of  Networks  Enabling  Targeting 

One  of  the  tenets  of  NCW  is  the  dramatic  (nonlinear)  improvement  in  FoS  capabilities  that  can 
be  achieved  through  the  networking  of  entities  in  the  Battlespace.  Metcalfe’s  Law,  for  example, 
has  been  cited  as  an  illustration  of  the  nonlinear  kinds  of  improvement  that  are  sought  by 
networking  the  FoS.’^  In  Metcalfe’s  Law,  the  number  of  connections  in  a  network  is  seen  to 
increase  proportionally  to  (nonlinear)  rather  than  N  (linear),  where  N  is  the  number  of  nodes 
in  the  network. 

Figure  1-3  illustrates  how  networking  of  the  systems  in  the  operational  example  of  Figure  1-2 
can  also  lead  to  nonlinear  improvement.  In  this  case,  networking  further  enables  the  use  of 
geographically  dispersed  forces,  which  allows  better  exploitation  of  the  laws  of  physics  for  the 
sensors.  The  results  in  the  figure  were  generated  by  computer  simulation.  The  contours  in  the 
figure  are  lines  of  constant  targeting  accuracy.  The  shaded  areas  are  those  regions  where 
targeting  accuracy  is  adequate  to  support  weapons  employment.  The  region  of  targeting  accuracy 
for  three  Guardrails  is  illustrated  in  the  left  panel  of  Figure  1-3.  The  addition  of  the  fourth  sensor 
at  sufficient  altitude  to  interoperate  with  the  Guardrail  sensors  exploits  the  laws  of  physics  to 
achieve  dramatic  improvements  in  targeting.  This  addition  might  require  a  new  air  vehicle  to 
achieve  a  useful  altitude.  A  future  high-altitude  unmanned  air  vehicle  (UAV),  for  example,  might 
take  on  a  mission  like  this.  The  right-hand  panel  shows  how  the  targeting  area  is  calculated  to 
increase  by  a  factor  of  five  when  the  single  high-altitude  sensor  is  integrated  into  the  Guardrail 
FoS.  This  is  one  kind  of  benefit  that  NCW  propounds  to  offer  through  the  proper  assemblage  of 
disparate  and  dispersed  entities. 


Using  Architectures  for  Research,  Development,  and  Acquisition 


8 


Targeting  Precision  (Predicted) 

1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 -  - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 - r 


Figure  1-3.  Illustration  of  Network  Centric  Warfare  Benefits 


Finally,  it  must  be  remembered  that  the  capabilities  enabled  by  networks  and  the  architecture  of 
the  network  will  be  determined  by  needs  and  objectives.  Force  coordination,  force  control,  and 
sensor  fusion  for  weapons  employment  will  all  have  different  requirements.  Additionally,  the 
network  architectures  for  each  of  these  uses  should  ultimately  be  integrated.  An  adaptation  of  the 
popular  graphic  from  OSD^^  depicted  in  Figure  1-4  is  used  to  illustrate  these  relationships. 


Ref:  Mr.  John  J.  Garstka,  Joint  Staff/J6Q 
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Figure  1-4.  Networking  the  Force 
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The  Role  of  Architectures 

How  then  have  architectures  been  used  in  FoS  systems  engineering?  Figure  1-4  hints  at  the  role 
of  architectures  by  representing  the  force  structure  and  command  structure  as  a  network  of  nodes 
that  are  associated  with  performance  metrics  at  the  FoS  level.  These  metrics  are  achieved 
through  the  interoperation  of  the  nodes.  To  use  architectures  to  support  FoS  systems  engineering, 
two  types  of  assessments  must  be  performed.  The  first  is  a  performance  assessment  of  systems 
and  collections  of  systems  conducted  through  traditional  modeling  and  simulation  methods. 
Unfortunately,  these  methods  usually  make  tacit  assumptions  about  interoperability  between  the 
nodes  that  are  not  addressed  by  existing  modeling  and  simulation  tools.  Accordingly,  the  second 
type  of  assessment  is  an  interoperability  assessment.  The  case  studies  in  Part  II  of  this  book 
devote  substantial  attention  to  the  use  of  architectures  for  interoperability  assessments.  The  most 
significant  accomplishment  that  has  emerged  from  the  case  studies  is  the  development  of 
common  architectural  exhibits  that  have  been  used  by  both  system  engineers  to  conduct 
performance  assessments  and  architects  to  perform  interoperability  assessments.  These  common 
exhibits  have  provided  a  very  necessary  concordance  between  FoS  performance  assessments  and 
interoperability.  Without  this  concordance,  FoS  performance  predictions  are  not  supportable. 

Summary 

The  challenge  for  DoD  in  developing  methods  to  integrate  multiple  capabilities  across 
developing  and  often  disparate  legacy  systems  can  be  met  with  an  FoS  systems  engineering 
process  that  is  architecture  based.  NCW  provides  an  exciting  opportunity  for  the  DoD  to  achieve 
new  capabilities  enabled  through  the  interoperation  of  systems.  The  architectural  methodology 
for  FoS  systems  engineering  and  acquisition  is  central  to  realizing  the  capabilities  achievable 
through  the  interoperation  of  systems.  Dramatic  improvements  in  FoS  capabilities,  gained 
through  the  interoperation  of  systems  which  in  turn  is  enabled  by  networks,  have  both  an  historic 
and  analytical  basis.  The  overview  of  the  problem  to  be  solved  and  the  architecture-based 
approach  to  the  solution  presented  in  this  introduction  will  be  expanded  in  the  chapters  that 
follow  and  illustrated  in  the  case  studies.  The  case  studies  and  architectural  methodology  should 
provide  the  reader  with  a  firm  understanding  of  how  to  use  these  methods  in  practice. 
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CHAPTER  2 

USING  ARCHITECTURES  IN  SYSTEMS  ENGINEERING  AND  ACQUISITION 
Purpose 

The  previous  chapter  introduced  the  concept  of  using  an  architectural  approach  to  assemble  an 
FoS  to  achieve  defined  mission  capabilities,  including  a  specific  example  of  NCW.  This  chapter 
provides  an  overview  of  how  the  DoD  Architecture  Framework  can  be  used  to  support  a 
capabilities-based  FoS  systems  engineering  process.  Effective  planning,  design,  and  analysis  are 
critical  throughout  the  development  of  the  FoS  to  ensure  cost-effective  achievement  of  mission 
objectives.  The  DoD  Architecture  Framework  products  can  be  used  as  tools  to  develop  integrated 
solutions  for  achieving  desired  mission  capabilities.  These  products  can  be  used  as  standardized 
templates  to  allow  operators,  engineers,  and  acquisition  professionals  to  describe  the  activities, 
functions,  and  systems  required  to  assemble  the  FoS.  The  adaptation  of  the  DoD  Architecture 
Framework  products  to  support  the  architecture  assessments  critical  for  developing  FoSs 
designed  to  achieve  specific  mission  capabilities  will  provide  DoD  professionals  with  effective 
tools  for  making  more  informed  acquisition  investment  decisions.  Exactly  how  these  products 
can  be  applied  in  order  to  support  acquisition  of  FoSs  designed  to  provide  specific  mission 
capabilities  is  illustrated  in  the  case  studies  in  Part  II  of  this  book. 

Architectural  Methodology 

Collective  mission  capabilities  are  derived  from  the  interrelationships  and  dependencies  between 
systems.  Not  surprisingly,  the  complexity  of  the  description  of  the  FoS  increases  rapidly  as  it 
moves  from  high-level  concepts  to  their  instantiation  by  physical  systems.  The  architectural 
methodology  is  part  of  a  systems  engineering  discipline  that  documents  “the  structure  of 
components,  their  relationships,  and  the  principles  and  guidelines  governing  their  design  and 
evolution  over  time.”'^ 

The  architecture  is  the  first  level  of  design  that  can  be  reasoned  about.  It  provides  the  framework 
for  analyzing  both  engineering  development  and  operational  uses  of  the  FoS.  It  also  provides  the 
basis  for  the  transformation  of  FoS  planning  and  acquisition  into  a  capabilities  based  strategy.*"^ 

To  support  FoS  systems  engineering  and  acquisition,  the  Architecture  Framework  products  can 
be  organized  into  five  product  groups  or  use  cases: 

■  Operational  Concept 

■  System  Functional  Mapping 

■  System  Interface  Mapping 

■  Architecture  Performance  and  Behavior 

■  Acquisition  Planning 

In  Figure  2-1,  these  groups  are  generally  ordered  (top  to  bottom)  by  the  anticipated  level  of 
complexity  associated  with  their  use.  However,  this  ordering  of  the  five  groups  should  not  be 
confused  with  how  the  products,  or  views,  are  developed.  Many  of  the  products  are  developed 
concurrently. 
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The  first  four  of  the  five  groups  of  products  can  he  generally  associated  with  the  four  steps  of 
classical  systems  engineering: 

■  Requirements  Analysis 

■  Functional  Analysis 

■  Synthesis 

■  Design  Verification 

While  FoS  systems  engineering  must  follow  the  principles  of  classical  systems  engineering,  the 
complexity  of  the  FoS  and  the  preponderance  of  legacy  systems  in  the  FoS  will  limit  the  system 
engineer’s  ability  to  apply  these  principles  in  practice.  Performing  requirements  analysis  to 
achieve  specific  FoS  capabilities  and  developing  a  functional  design  for  the  FoS  are,  however, 
both  manageable  tasks.  The  architecture  products  that  emerge  from  requirements  and  functional 
analyses  become  stable  views  of  the  FoS  that  are  much  simpler  to  understand  than  the  underlying 
and  constantly  changing  physical  architecture.  The  FoS  synthesis  provides  the  critical  mapping 
of  legacy  systems  into  the  functional  view  of  the  architecture  for  the  FoS  and  enables 
determination  of  how  the  remaining  trade  space  might  be  used  for  new  systems  and  system 
improvements.  Performing  FoS  design  verification  is  reduced  in  complexity  by  focusing  on 
threads  of  systems  that  provide  the  supporting  functionality  for  specific  mission  capabilities. 


Using  Architectures  in  Systems 
Engineering  &  Acquisition 


Rda 

Chief 

•Engineer 


Operational  Concept 


^ov^ 

i”  bv-4j  "bv-5 

“P 

fa 

Lesser 


The  Role  of  Engineering  and  Technology 


Greater 


System  Functional  Mapping 


C\/  *1  rr? 

'■ - ;  0  -3 

SV-4 

"sV-5- 

1st  Order  Analysis: 
Functionality 


System  Interface  Mapping 


DRM:  Design  Reference  Mission 
OpSit  Operationai  Situation 
TTP:  Tactics,  Techniques,  Procedurels 


CV-6  Capabilities  Evoiution  Description 
OV-1  Highlevel  Operational  Concept  Graphic 
OV-2  Operational  Node  Connectivity  Description 
OV-3  Operational  Information  Exchange  Matrix 
OV-4  Organizational  Relationships  Chart 
OV-5  Operational  Activity  Model 
OV-6C  Operational  Event/Trace  Description 
SV-1  Systems  Interface  Description 
SV-2  Systems  Communication  Description 
SV-3  Systems  Matrix 
SV-4  Systems  Functionality  Description 
SV-5  Operational  Activity  to  Systems  Function 
Traceability  Matrix 

SV-6  Systems  Data  Exchange  Matrix 

SV-7  System  Performance  Parameters  Matrix 

SV-8  System  Evolution  Description 

SV-9  System  Technology  Forecast 

SV-10  System  Activity  Sequence  &  Timing 

TV-1  Technical  Standards  Profile 

TV-2  Standards  Technology  Forecast 


^OV-2  SV-t  i  TV-1^ 


2nd  Order  Analysis: 
Static  Interoperability 


“OV-3  SV-2  =  sy-6 


Note:  There  are  dependencies  between  the  Architecture 
products  that  are  not  shown  in  the  System 
Engineering  fiow.  Many  of  the  products  are 
developed  concurrently. 


I  I  Architecture  Performance 
\  and  Behavior 


Acquisition  Planning 


SV-8 


TV-2 


r  SV-9 


cv-e 


Architectures  Provide  the  Framework  for 
FoS/SoS  Systems  Engineering  &  Acquisition 


zOV-6C 


SV-10 


SV-7 


3rd  Order  Analysis: 
Dynamic  Interoperability 


Figure  2-1.  Using  the  Architecture  Framework  in  FoS  Systems  Engineering  and  Acquisition 


The  following  paragraphs  describe  each  of  the  five  Architecture  Framework  product  groups  and 
introduce  the  Framework  products  that  are  used  to  support  them.  This  basic  overview  of  the 
architectural  methodology  is  intended  to  provide  the  reader  with  a  foundation  that  will  be 
expanded  through  a  demonstration  of  how  the  products  are  used  in  practice  in  the  case  studies 
that  comprise  Part  II  of  the  book. 
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Operational  Concept 

The  operational  concept  should  he  a  high  level  abstraction  of  the  problem  to  be  solved  and  the 
proposed  approach  to  solve  the  problem.  It  can  also  include  boundary  conditions  and  invariants 
(i.e.,  things  not  in  the  trade  space  of  the  solution).  Description  of  the  operational  concept  can  be 
supported  through  the  use  of  three  Architecture  Framework  products  or  Operational  Views 
(OVs)  while  keeping  a  fourth  product  mind: 

■  OV-1,  High-Level  Operational  Concept  Graphic:  provides  a  high  level  description  of  what 
the  military  force  is  and  its  intended  effects  on  the  defined  threat 

■  OV-5,  Operational  Activity  Model:  provides  the  first  descriptions  of  how  the  military  force 
will  achieve  its  intended  effects 

■  OV-4,  Organizational  Relationships  Chart:  documents  the  control  relations  over  the 
operational  activities,  establishing  by  what  authority  or  mechanisms  activities  are  directed  to 
execute  or  remain  idle 

■  OV-2,  Operational  Node  Connectivity  Description:  offers  an  enterprise  view  of  the 
architecture  and  provides  meaningful  groupings  of  the  activities  in  the  Operational  Activity 
Model;  these  groupings  can  be  thought  of  as  task-oriented  cells  where  work  is  accomplished 

These  products  lay  the  foundation  for  systems  development  and  facilitate  communication  by 
providing  context,  orientation,  and  focus.  They  also  serve  as  the  entry  point  for  requirements 
flow  down  into  the  architecture.  These  architecture  products  are  the  first  artifacts  that  support  the 
feasibility  of  the  concept.  They  will  help  answer  the  following  questions:  What  is  the  problem  to 
be  solved,  what  is  the  proposed  approach  for  solving  that  problem,  and  is  that  approach  feasible? 
The  case  studies  in  Part  II  of  this  book  discuss  the  use  of  the  architecture  products  in  supporting 
concept  and  requirements  development  and  address  the  specific  architecture  views  used  to  gather 
and  collect  data  to  build  an  analytical  framework. 

System  Functional  Mapping 

Because  most  FoSs  are  highly  complex,  simply  keeping  track  of  the  data  describing  the  systems, 
their  relationships,  and  their  evolution  is  an  overwhelming  task.  The  System  Functional  Mapping 
of  the  solution  provides  a  stable  model  that  facilitates  the  management  of  this  information  as 
well  as  the  mapping  of  systems  to  functions.  The  system  functional  mapping  is  supported  by 
three  Architecture  Framework  products  or  System  Views  (SVs): 

■  SV-4,  Systems  Functionality  Description:  provides  a  list  of  system  functions  that  will  be  used 
to  enable  or  execute  operational  activities 

■  SV-5,  Operational  Activity  to  Systems  Function  Traceability  Matrix:  aligns  individual 
system  functions  with  the  individual  operational  activities  they  enable  or  execute 

■  SV-3,  Systems^  Matrix:  aligns  systems  to  functions,  operational  activities,  and  to  other 
systems 

Together,  these  products  provide  the  linkage  and  traceability  of  capabilities  and  requirements 
flow-down  between  the  operational  and  physical  views.  The  functional  view  is  also  the  first  level 
of  the  architecture  that  is  appropriate  for  systems  assessments.  The  products  provide  the  basis  to 
answer  the  following  question:  Does  the  FoS  system  architecture  provide  the  functionality  to 
support  the  desired  mission  capabilities?  Assessments  using  this  functional  group  of  products 
provide  the  basis  for  a  first  order  analysis  of  combinations  of  systems  proposed  to  comprise  the 
FoS.  Chapters  3  and  4  in  Part  II  provide  greater  detail  on  System  Functional  Mapping  and 
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Assessment  and  speeifieally  discuss  the  use  of  each  Framework  product  in  conducting  this  step 
in  the  process.  In  the  systems  engineering  process,  attention  will  be  focused  on  an  FoS  that  is 
intended  to  solve  the  problems  laid  out  in  the  High  Level  Operational  Concept  (OV-1).  For 
example,  an  analysis  of  gaps  and  overlaps  will  reduce  the  size  of  the  system  trade  space.  The 
result  of  this  first  order  architecture  analysis  is  the  starting  point  for  systems  engineering  trade¬ 
off  analysis,  and  it  is  discussed  in  detail  in  Chapter  5  of  this  book. 

System  Interface  Mapping 

The  system  interface  mapping  builds  all  views  —  operational,  system,  and  technical  —  of  the 
connectivity  between  the  FoS  systems.  System  interface  mapping  can  be  supported  through  the 
use  of  six  Architecture  Framework  products,  which  are  a  mixture  of  OVs,  SVs,  and  Technical 
Views  (TVs): 

■  OV-2,  Operational  Node  Connectivity  Description:  provides  meaningful  groupings  of  the 
activities  in  the  Operational  Activity  Model;  these  groupings  can  be  thought  of  as  task- 
oriented  cells  where  work  is  accomplished 

■  OV-3,  Operational  Information  Exchange  Matrix:  defines  fhe  Information  Exchange 
Requirements  (lERs)  across  the  three  basic  entities  of  the  operational  view  (activities, 
operational  nodes,  and  information  flow) 

■  SV-1,  Systems  Interface  Description:  links  the  operational  nodes  and  system  views  of  the 
architecture 

■  SV-2,  Systems  Communications  Description:  represents  the  specific  communications 
systems  pathways  or  networks  and  the  details  of  their  configurations  through  which  the 
physical  nodes  and  systems  interface 

■  TV-1,  Technical  Standards  Profile:  provides  the  set  of  rules  that  govern  system 
implementation  and  operation 

■  SV-6,  System  Data  Exchange  Matrix:  creates  end-to-end  views  of  system  information  and 
service  exchanges 

From  the  point  of  view  of  systems  engineering  trades,  these  views  provide  the  basis  to  answer 
the  following  question:  Have  the  appropriate  standards  been  applied  and  the  levels  of 
interoperability  been  properly  aligned  so  that  the  individual  systems  in  the  FoS  can  be  expected 
to  interoperate  with  each  other  successfully  to  enable  the  functionality  sought  for  the  FoS?  The 
architecture  views  from  the  framework  used  to  capture  this  data  and  the  process  used  to  conduct 
the  analysis  are  discussed  in  detail  in  Chapters  3  and  4  of  Part  II. 

Architecture  Performance  and  Behavior 

The  system  functional  mapping  and  the  system  interface  mapping  provide  key  insights  into  the 
functionality  and  connectivity  of  the  architecture  with  traceability  to  operational  capability.  As 
such,  these  uses  of  Framework  Architecture  products  provide  an  early  validation  of  the 
architecture  and  serve  to  answer  the  following  question:  What  can  the  architecture  enable  the 
FoS  to  actually  do?  Yet  the  architecture  cannot  be  validated  until  it  can  be  executed  as  a  flow  of 
events,  a  task  that  can  be  accomplished  only  through  review  of  the  products  of  its  performance 
and  behavior.  The  group  of  architecture  products  proposed  to  support  the  use  case  of 
performance  and  behavior  can  serve  to  answer  the  following  questions:  How  well  does  the 
architecture  perform  (to  deliver  mission  capabilities),  and  does  it  behave  in  ways  acceptable  to 


Using  Architectures  for  Research,  Development,  and  Acquisition 


15 


the  users?  This  use  case  can  be  supported  with  three  existing  Architecture  Framework  products 
and  the  addition  of  one  new  product: 

■  OV-6c,  Operational  Event/Trace  Description:  enables  the  traceability  of  actions  in  a  scenario 
or  critical  sequence  of  events  to  address  the  executability  (or  dynamic  validity)  of  the 
operational  view  of  the  architecture 

■  SV-10,  System  Activity  Sequence  and  Timing  Description:  includes  a  Systems  Rules  Model, 
a  Systems  State  Transition  Description,  and  a  Systems/Event  Trace  Description 

■  SV-7,  Systems  Performance  Parameters  Matrix:  builds  on  the  Systems  Interface  Description 
(SV-1)  to  depict  the  current  performance  characteristics  of  each  system  and  the  expected  or 
required  performance  characteristics  at  specified  times  in  the  future 

■  Executable  Model  (new  product):  required  for  both  validation  and  analysis 

While  these  products  are  necessary  to  support  system  selection  decisions  that  reside  in  the 
domain  of  FoS  systems  engineering  trade  studies  (i.e.,  performance  and  capabilities  versus  cost 
and  risk),  they  are  the  most  labor  intensive  of  the  five  groups  (use  cases)  to  generate.  Further 
detail  on  this  set  of  architecture  views  is  provided  in  Chapters  5  and  7  of  Part  IT 

Acquisition  Planning 

To  support  capabilities-based  acquisition  planning,  it  is  critical  to  align  the  evolution  of  systems, 
technologies,  and  standards  with  the  evolving  mission  capability  requirements  of  the  FoS. 
Describing  the  acquisition  strategy  requires  three  existing  Architecture  Framework  products  and 
a  proposed  new  product  called  a  Capability  View  (CV): 

■  SV-9,  Systems  Technology  Forecast:  provides  a  detailed  description  of  emerging 
technologies  and  specific  hardware  and  software  products 

■  TV-2,  Technical  Standards  Forecast:  provides  a  detailed  description  of  emerging  technology 
standards  relevant  to  the  systems  and  business  processes  covered  by  the  architecture 

■  SV-8,  Systems  Evolution  Description:  describes  plans  for  “modernizing”  a  system  or  suite  of 
systems  over  time 

■  CV-6,  Capability  Evolution  Description:  provides  a  high-level  graphic  for  managers  and 
executives  to  use  in  providing  oversight  of  FoS  alignment  during  acquisition 

Together,  these  products  provide  a  description  of  the  evolution  and  acquisition  of  the  system 
improvements  for  the  FoS  that  are  traceable  to  mission  capability  requirements.  They  help 
answer  the  following  question:  what  changes  in  systems,  standards,  and  capabilities  will  affect 
the  ability  of  the  FoS  to  deliver  the  desired  mission  capability?  Chapter  5  provides  additional 
information  on  using  the  Architecture  Framework  products  to  support  acquisition  planning. 

Capabilities-Based  FoS  Systems  Engineering 

In  FoS  systems  engineering,  the  operational  concept  must  clearly  be  tied  to  capabilities.  The 
Joint  Requirements  Oversight  Council  (JROC)  has  defined  an  operational  concept  to  be  an  end- 
to-end  stream  of  activities  that  defines  how  Force  elements,  systems,  organizations,  and  tactics 
combine  to  accomplish  a  military  task.*^  This  must  be  distinguished  from  a  concept  of  operations 
(CONOPS),  which  is  a  statement  of  the  Commander’s  assumptions  or  intent  with  regard  to  an 
operation.  The  CONOPS  is  frequently  embodied  in  campaign  plans  and  operations  plans  and 
especially  in  operations  plans  that  cover  a  series  of  operations  to  be  carried  out  simultaneously  or 
in  succession.*^ 
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Joint  doctrine  has  defined  the  term  “capability”  with  a  simple  and  authoritative  definition:  a 
capability  is  the  ability  to  execute  a  specified  Course  of  Action  (COA)^^.  A  COA  is  just  a 
possible  plan  available  to  an  individual  or  commander  that  would  accomplish  (or  is  related  to  the 
accomplishment)  of  a  mission.  These  definitions  are  easily  adapted  to  the  architectural 
methodology.  In  this  sense,  COAs  are  simply  sequences  of  operations  that  can  be  executed  to 
support  or  accomplish  a  mission.  The  term  “capability,”  then,  has  a  rigorous  meaning  in  both  its 
military  and  engineering  usage.  The  next  part  of  this  book  will  illustrate  how  architectures  can  be 
used  in  FoS  engineering  to  support  delivery  of  mission  capability. 

Summary 

The  DoD  Architecture  Framework  products  serve  as  tools  for  supporting  a  capabilities-based 
FoS  systems  engineering  process.  The  Framework  views  provide  a  common  language  that  can  be 
used  among  operators,  engineers,  and  acquisition  professionals  in  performing  architectural 
analysis  to  support  better  acquisition  decisions  focused  on  achieving  desired  mission  capabilities 
within  an  FoS.  Part  II  of  this  book  illustrates  how  these  tools  can  be  put  into  practice  in  pursuing 
NCW  capabilities  forFoSs. 
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PART  II 

ARCHITECTURAL  CASE  STUDIES 

The  case  studies  presented  in  this  part  of  the  book  use  the  previously  introduced  architectural 
methodology  to  develop  more  fully  the  NCW  concept  introduced  in  Chapter  1 .  The  presentation 
of  these  case  studies  is  intended  to  serve  two  purposes: 

•  To  provide  an  abstraction  of  NCW  that  will  support  Joint  Vision  2020^^ 

•  To  show  how  the  architecture  methodology  provides  traceability  of  operational  capabilities 
to  the  functionality  and  connectivity  of  the  FoS 

This  part  of  the  book  begins  with  an  overview  of  how  the  architecture  products  introduced  in 
Chapter  2  can  be  used  to  support  the  development  of  NCW  concepts.  Chapter  3  demonstrates  at 
an  abstract  level  how  these  products  provide  a  framework  to  describe  a  mission  warfare  area  and 
to  demonstrate  the  logical  validity  of  the  mission  and  system  architecture.  It  discusses  the 
methods  used  in  building  a  warfare  mission  architecture  with  traceability  of  FoS  frmctionality 
and  connectivity  to  capability  objectives.  In  other  words,  it  shows  how  the  methodology  provides 
an  engineering  framework  to  describe  the  way  in  which  mission  capabilities  are  achieved 
through  the  interoperation  of  systems.  Part  II  continues  with  four  more  case  studies  that  further 
illustrate  the  architectural  methodology  for  FoS  systems  engineering.  Each  of  these  case  studies 
focuses  on  a  different  aspect  of  the  architectural  methodology  and  its  application.  The  detailed 
case  study  presented  in  Chapter  4  illustrates  the  use  of  the  three  basic  groups  of  products  in 
addressing  a  specific  warfare  application,  Precision  Engagement.  The  next  case  study,  presented 
in  Chapter  5,  discusses  the  use  of  the  architecture  products  in  support  of  Fleet  Battle  Experiment 
India  (FBE-I).  This  chapter  focuses  on  how  alternative  systems  that  could  instantiate  the 
architecture  can  be  assessed  in  order  to  build  an  acquisition  plan.  It  also  provides  the  reader  with 
a  better  understanding  of  the  need  for  alignment  of  systems  in  their  procurement  schedules  to 
provide  the  resources  necessary  to  support  the  FoS  systems  engineering  and  integration  that 
enable  the  interoperation  of  systems  in  the  family.  Chapter  6,  a  case  study  on  Joint  Maritime 
Command  and  Control  Capability,  takes  a  more  detailed  look  at  command  and  control,  primarily 
from  an  operational  view.  The  final  case  study,  a  Coalition  Partner  Integrated  Air  Picture,  is 
presented  in  Chapter  7.  It  demonstrates  how  a  capability  such  as  an  integrated  air  picture  for 
coalition  partners  can  be  used  as  an  operational  node  within  a  mission  warfare  architecture.  It 
also  initiates  the  discussion  of  how  executable  architectures  can  be  used  to  assess  architecture 
performance  and  behavior.  Taken  in  total,  these  case  studies  provide  the  reader  with  an 
illustration  of  how  the  Architecture  Framework  products  can  be  implemented  to  support  the 
achievement  of  mission  capability  based  acquisition. 
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CHAPTER  3 

INTRODUCTION  TO  NCW  CASE  STUDIES 


Purpose 

This  introductory  chapter  to  the  case  studies  offers  the  reader  foundational  information  on  NCW 
and  the  mission  effects  it  offers  through  the  interoperation  of  systems.  To  provide  this 
foundation,  it  guides  the  reader  through  an  abstraction  of  a  simple  example  of  NCW  Precision 
Engagement  motivated  by  the  Guardrail  example  provided  in  Figure  1-2  in  Chapter  1.  The 
discussion  in  this  chapter  is  designed  to  be  similar  to  the  manner  in  which  an  architect  would 
work  with  a  system  developer  and  a  military  operator  in  that  it  starts  with  a  conceptual 
illustration  of  the  proposed  solution  to  the  problem.  It  then  shows  how  the  first  three  basic 
groups  of  architecture  products  introduced  in  Chapter  2  (the  operational  concept,  the  system 
functional  mapping,  and  the  system  interface  mapping)  support  the  development  of  NCW 
concepts.  It  discusses  how  these  basic  architecture  products  provide  a  framework  to  describe  a 
mission  warfare  area  and  demonstrate  the  logical  validity  of  the  mission  and  system  architecture. 
Establishing  the  logical  validity  of  the  architecture  is  the  first  step  toward  demonstrating  that  the 
FoS  architecture  has  the  requisite  interoperability  to  support  the  mission.  Without  this 
interoperability,  the  performance  claims  made  in  Figure  1-3  would  be  unsupportable.  The 
information  presented  in  this  chapter  will  be  helpful  to  readers  as  they  review  the  case  studies 
contained  in  Chapters  4,  5,  6,  and  7. 

Translating  the  NCW  Mission  into  Architectural  Views 

As  noted  earlier  in  this  book,  NCW  relies  on  information  sharing,  information  quality,  shared 
situational  awareness,  collaboration,  and  self-synchronization  to  deliver  a  dramatic  increase  in 
mission  effectiveness.  In  short,  it  is  focused  on  leveraging  knowledge  superiority  enabled  by 
technology  to  conduct  effects-based  military  operations.  In  this  context,  it  is  the  mission  effects 
achieved  through  the  interoperation  of  systems  enabled  by  networks  -  not  the  networks 
themselves  -  that  are  the  focus  and  substance  of  NCW.  It  is  easy  to  understand  how  achieving 
the  increased  mission  effects  enabled  through  NCW  would  be  beneficial  to  the  warfighter.  The 
acquisition  challenge  is  to  identify  specifically  what  must  occur  to  make  those  increased  mission 
effects  a  reality.  What  systems  and  information  are  needed  to  bring  about  this  increase,  and  how 
can  they  be  integrated  to  make  it  happen?  The  complexity  associated  with  answering  these 
questions  led  to  the  organization  of  the  architectural  views  into  the  five  groups  of  views 
presenfed  in  Chapter  2  (Figure  2-1).  These  architectural  views  enable  systems  architects, 
engineers,  and  acquisition  specialists  to  move  from  defining  the  operational  concept  to 
identifying  and  analyzing  the  actual  systems  and  interfaces  that  will  be  needed  to  perform  the 
required  activities  and  functions,  to  provide  the  necessary  communication  and  information 
exchanges,  and  to  execute  the  NCW  mission. 

The  acquisition  challenge  is  usually  met  by  working  with  military  operators  to  establish  a 
conceptual  solution  like  the  one  illustrated  in  Figure  3-1.  The  architect  must  work  with  military 
operators,  systems  engineers,  and  other  stakeholders  to  develop  architectural  views  leading  to  a 
solution  that  is  operationally  sound,  technically  feasible,  and  cost  effective.  The  first  element  of 
the  graphic.  Figure  3- la,  was  first  introduced  in  Chapter  1  and  illustrates  an  instance  of  the 
specific  NCW  mission  of  Precision  Engagement.  While  the  illustration  in  Figure  3- la  provides 
information  on  the  force  elements  and  the  mission  objective  and  context,  it  fails  to  show 
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information  that  will  be  critical  to  achieving  the  technical  solution.  The  lightning  bolts  in  the 
graphic,  for  example,  show  that  information  will  be  exchanged,  but  no  information  is  provided 
on  how  the  information  will  flow,  what  systems  make  this  information  exchange  possible,  or 
what  the  information  needs  are.  This  information  is  essential  to  making  the  NCW  vision  for  this 
mission  a  reality.  The  second  element  of  the  graphic.  Figure  3- lb,  goes  a  bit  further  by  providing 
a  very  high-level  systems  architecture.  The  physical  systems  identified  in  the  conceptual  solution 
are  abstracted  as  sensors,  processors,  and  weapons  that  interoperate  through  networks.  A  high- 
level  paradigm  of  Detect,  Control  (of  the  weapon),  and  Engage  can  be  used  to  organize  the 
concept.  Under  this  paradigm,  the  operational  concept  for  Precision  Engagement  of  a  target  in 
the  Battlespace  can  be  described  using  a  combination  of  these  basic  operational  activities. 
Specifically,  the  target  in  the  Battlespace  is  first  detected,  and  then  the  weapon  used  to  engage 
the  target  is  controlled  (i.e.,  the  fire  control  solution  is  developed)  using  these  detections.  The 
systems  in  the  conceptual  solution  presented  in  Figure  3- la  can  be  allocated  in  a  geographically 
distributed  way  that  can  then  be  abstracted  and  captured  with  an  architectural  diagram  (Figure  3- 
Ib).  The  use  of  this  basic  diagram  allows  operational  capabilities  to  be  traced  to  systems  and 
system  interoperation.  With  the  architectural  formalism  of  this  diagram,  it  becomes  obvious  that 
a  network  between  the  data  processor  and  the  weapon  may  have  been  overlooked  in  the 
conceptual  solution.  The  architect  must  then  work  with  the  military  operator  to  identify  what 
cormection  was  intended.  While  the  alignment  of  systems  to  operational  capabilities  offers  a 
helpful  first  step  in  identifying  the  missing  pieces  of  the  architecture,  it  still  fails  to  provide  the 
information  exchange  elements  that  are  missing  from  Figure  3- la. 

The  architecture  products  discussed  and  illustrated  in  the  remainder  of  this  chapter  show  how  the 
operational  concept  in  Figure  3-la  and  the  notional  architecture  presented  in  Figure  3-lb  are  validated 
through  development  and  analysis  of  operational  and  functional  views  and  the  implied  interfaces. 
These  views  will  establish  the  logical  validity  of  the  high-level  systems  architecture  presented  in 
Figure  3- lb,  which  is  the  first  step  in  determining  if  the  mission  illustrated  in  Figure  3- la  can 
actually  be  accomplished. 

NCW  Operational  Concept 

The  first  step  in  developing  architecture  products  for  an  NCW  mission  is  to  develop  operational 
concept  views.  As  noted  in  Chapter  2,  the  operational  concept  is  a  high-level  abstraction  of  the 
problem  to  be  solved  and  the  proposed  approach  for  solving  it.  These  products  lay  the  foundation 
for  systems  development  and  facilitate  communication  by  providing  context,  orientation,  and 
focus.  They  also  serve  as  the  entry  point  for  requirements  flow  down  into  the  architecture.  They 
also  provide  the  further  refinement  of  definitions  that  is  necessary  to  make  these  views  more 
useable  as  engineering  products.  These  operational  concept  architecture  products  are  the  first 
artifacts  that  support  the  feasibility  of  the  concept.  The  NCW  Operational  Concept  can  be 
described  using  four  architecture  products: 

•  High-Eevel  Operational  Concept  Graphic  (OV-1) 

•  Operational  Activity  Model  (OV-5) 

•  Operational  Node  Connectivity  Description  (OV-2) 

•  Organizational  Relationships  Chart  (OV-4) 
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ASAS:  All  Source  Analysis  System 

ATACMS:  Advanced  Tactical  Cruise  Missile  System 

C2:  Command  and  Control 

CDL:  Common  Data  Link 
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Figure  3- la.  Example  of  Networks  Enabling  Precision  Engagement 
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Figure  3- lb.  Abstraction  of  Targeting  Example 

Figure  3-1.  Architectural  Abstraction  for  NCW  Precision  Engagement  Example 
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These  products  will  help  provide  the  groundwork  for  answering  the  following  questions:  What  is 
the  problem  to  be  solved,  what  is  the  proposed  approach  for  solving  it,  and  is  that  approach 
feasible? 

The  Precision  Engagement  targeting  example  illustrated  in  Figure  3-1  can  be  easily  related  to 
these  four  basic  operational  views  of  the  architecture.  The  conceptual  solution  (Figure  3- la) 
corresponds  to  the  High-Fevel  Operational  Concept  Graphic  (OV-1).  The  Detect-Control- 
Engage  paradigm  illustrated  in  Figure  3-lb  corresponds  to  the  Operational  Activity  Model  (OV- 
5).  The  use  of  the  Detect-Control-Engage  paradigm  to  organize  assets  that  perform  specific  tasks 
and  interoperate  with  each  other  corresponds  to  the  Operational  Node  Connectivity  Description 
Diagram  (OV-2),  which  is  discussed  in  detail  later  in  this  chapter.  The  final  product. 
Organizational  Relationships  Chart  (OV-4),  is  not  addressed  in  the  conceptual  solution  in  Figure 
3-1.  Even  so,  it  is  apparent  that  the  way  command  authority  is  allocated  to  individual  weapon 
system  (System  of  Systems  (SoS))  commanders  significantly  affects  how  the  military  force 
fights  and  its  ability  to  achieve  speed  of  effects  in  the  Battlespace. 

The  central  architectural  views  can  then  be  used  to  build  an  organizing  operational  view  (the 
Operational  Event/Trace  Nodal  Description)  that  is  based  on  two  additional  architecture 
products: 

•  Operational  Event/Trace  Description  (OV-6c) 

•  Operational  Information  Exchange  Matrix  (OV-3) 

To  provide  a  better  understanding  of  how  the  operational  concept  products  are  used  in  an  NCW 
context,  each  product  is  described  in  the  following  paragraphs. 

NCW  High-Level  Operational  Concept  Graphic  (OV-1) 

Figure  3 -2a  illustrates  a  high-level  operational  concept  that  can  be  used  to  describe  the  high-level 
warfare  areas.  This  operational  concept  has  five  key  elements: 

•  Command  authority 

•  Military  force 

•  Threat 

•  Battlespace 

•  Effects 

The  overarching  concept  is  that  the  command  authority  controls  the  military  force,  which  can  be 
directed  to  affect  a  threat  within  a  Battlespace.  Understanding  this  concept  is  critical  to 
understanding  mission  capability,  which  is  defined  as  the  means  to  use  military  force  to  achieve 
an  intended  and  measurable  effect  within  the  Batttlespace.’^  At  the  highest  level  of  abstraction, 
the  five  elements  that  define  the  High-Level  Operational  Concept  are  undefined  terms  that  will 
be  more  fully  defined  as  the  architecture  is  developed.  Four  of  these  five  elements  are  accounted 
for  in  the  conceptual  solution  (Figure  3- la).  The  command  relationship  (which  corresponds  to 
the  Organizational  Relationships  Chart  (OV-4))  is  the  one  element  that  is  not  accounted  for  in 
the  conceptual  solution.  Figure  3-2a  addresses  the  command  relationship.  In  order  to  discuss  the 
network-centric  aspects  of  this  concept,  the  military  force  must  be  decomposed  into  an  FoS, 
which  is  illustrated  in  Figure  3-2b  as  an  integrated  family  of  SoSs.  This  is  a  boundary  condition 
in  the  NCW  operational  concept. 
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Figure  3-2a.  Key  Elements  of  the  Operational  Concept  for  Warfare  Areas 


Figure  3-2b.  Network  Centric  Aspect  of  the  Military  Force 


Figure  3-2.  Fligh-Level  Operational  Concept  Graphic  for  NCW  (OV-1) 

The  NCW  concept  is  part  of  an  evolution  that  military  systems  have  been  undergoing  as  modem 
computers  and  communications  have  evolved.  Twenty-first  century  NCW  concepts  are  the  basis 
for  the  operational  constmct  and  architectural  framework  for  the  full  spectmm  of  warfare  in  the 
Information  Age,  which  involves  the  integration  of  warriors,  sensors,  networks,  command  and 
control,  platforms,  and  weapons  into  a  networked,  distributed  combat  force,  scalable  across  the 
spectmm  of  conflict  from  seabed  to  space  and  from  sea  to  land.  NCW  provides  for  the 
development  of  interoperable  and  horizontally  integrated  concepts  and  technologies  into  a  highly 
adaptive,  human-centric,  comprehensive  family  of  systems  to  provide  near-real-time  executable 
decision-making  information  throughout  the  Battlespace.  NCW  capabilities  will  be  built  to 
conform  to  joint  architectural  frameworks  that  will  link  current  and  fixture  sensors,  command  and 
control  elements,  and  weapons  systems  in  a  robust,  secure,  and  scalable  way.  Information  will  be 
converted  to  actionable  knowledge  and  disseminated  to  a  dispersed  combat  force,  enabling  the 
rapid  concentration  of  the  full  power  of  the  sea,  air,  land,  and  space  components  while  greatly 
reducing  the  quantity  of  required  forces  and  assets.  Information  Age  warfare  also  emphasizes  the 
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human  factor  in  the  development  of  advanced  teehnologies.  This  philosophy  aeknowledges  that 
the  warrior  is  a  premier  element  of  all  operational  systems. 

Today,  NCW  is  moving  from  concept  to  reality.  Initial  efforts  will  focus  on  integrating  existing 
networks,  sensors,  and  eommand  and  eontrol  systems.  In  the  years  ahead,  NCW  will  enable  the 
Joint  Services  to  employ  a  frilly  netted  force,  engage  with  distributed  combat  power,  and 
eommand  with  increased  awareness  and  speed. 

Network  eentrieity  is  obviously  a  key  element  of  the  concept,  but  it  must  be  remembered  that  network 
centricity  is  a  warfare  enabler  that  must  always  be  discussed  in  the  context  of  the  warfare  mission.  To  do 
otherwise  would  be  to  leave  the  “W”  out  of  NCW.  NCW  prineiples  and  architeetures  can  be  applied 
to  any  and  all  of  the  five  Joint  Warfare  Architecture  (JWAR)  high-level  areas: 

•  Power  projection 

•  Sea  dominance 

•  Air  dominance 

•  Space  dominance 

•  Information  superiority 

These  warfare  areas  ean  be  used  to  organize  and  focus  the  meaning  of  the  increased  mission 
effectiveness  to  be  enabled  by  the  tenets  of  NCW.  This  suggests  that  warfare  mission  capabilities 
ean  be  divided  into  eomponents  related  to  the  Battlespaee.  There  are  five  physieal  components 
(undersea,  sea,  land,  air,  and  space)  and  one  information  component  (cyberspace).  The  area  of 
operation  (AO)  for  the  military  forces  provides  a  seeond  dimension  for  describing  components  of 
mission  capabilities.  Joint  doctrine  defines  the  AO  as  an  operational  area  identified  by  the  JFC 
for  land  and  sea  forces  and  differentiated  from  the  operational  area  in  that  it  does  not  typically 
encompass  the  entire  operational  area.  It  is  therefore  reasonable  to  introduce  an  AO  component 
based  on  the  same  localities  used  in  the  JWAR  deeomposition. 

Figure  3-3  summarizes  the  mission  eapability  eomponents  for  the  Precision  Engagement 
example  shown  in  Figure  3- la.  This  warfare  mission  capability  will  be  discussed  in  detail  in  the 
ease  study  in  Chapter  4.  As  shown  in  the  matrix.  Precision  Engagement  causes  effeets  in  the  Battlespaee 
against  targets  on  land  or  against  the  cyberspace  through  which  they  operate.  Precision 
destruction  of  the  target  and/or  disruption  of  the  target’s  operations  through  focused  effeets  on  the 
target  or  the  target’s  cyberspace  are  the  Battlespaee  effects  of  the  Precision  Engagement  example. 


Battlespaee  Components 


Area  of 
Operation 

Area  of  Batt 

espace  Effects 

Undersea 

Sea 

Land 

Air 

Space 

Cyberspace 

Undersea 

Sea 

Land 

Air 

•/ 

•/ 

Space 

Cyberspace 

•/ 

Figure  3-3.  Mission  Capability  Components  for  Precision  Engagement  Example^ 


^  A  mission  capability  component  is  a  Battlespaee  component  affected  from  an  area  of  operation. 
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Network  centricity  can  enable  several  warfare  capabilities: 

•  Speed  of  effects 

•  Massing  of  effects 

•  Coordinated  operations  from  dispersed  assets 

The  activity  model  must  be  at  a  sufficient  level  of  detail  to  show  how  the  activities  lead  to  effects 
(and  capabilities)  in  the  execution  model.  Moving  from  the  operational  concept  into  operational 
activities  is  the  subject  of  the  next  section  in  this  chapter. 

Moving  from  the  Operational  Concept  to  Activities 

Establishing  the  high-level  operational  concept  for  the  NCW  mission  is  critical  to  moving 
forward  in  developing  and  ensuring  the  validity  of  an  architecture  that  can  support  a  mission.  But 
once  the  concept  is  established,  the  systems  architect  or  engineer  must  drill  down  from  the 
concept  to  determine  how  the  conceptual  mission  will  be  executed.  In  any  NCW  mission,  the 
critical  enabling  factor  is  the  ability  to  exchange  the  right  information  and  services  at  the  right 
time  and  place.  To  deliver  this  enabling  capability,  the  systems  architect  must  identify  the 
information  needs,  types  of  exchange,  and  exchange  abilities  associated  with  the  NCW  mission. 
The  operational  concept  introduced  in  Figure  3- la  illustrates  this  point.  As  shown  in  the  graphic, 
both  TRIXS  and  CDL  are  being  used  for  information  transfer,  but  there  is  no  way  to  know  that 
CDL  is  taking  raw  data  from  its  sources,  while  TRIXS  is  using  processed  data.  Obviously,  this 
information  is  crucial  to  successful  mission  execution.  Understanding  what  the  systems  are  doing 
at  the  engineering  level  is  part  of  understanding  the  operational  concept.  The  key  point  is  that  the 
information  needs,  types,  and  functional  flow  drive  the  feasibility  of  the  architecture. 
Determining  these  critical  information  exchange  requirements  begins  with  an  analysis  of  the 
operational  activities  that  support  mission  execution. 

Operational  Activity  Model  (OV-5) 

The  Architecture  Framework  describes  the  Operational  Activity  Model  (OV-5)  as  the  applicable 
activities  associated  with  the  architecture;  the  data  and/or  information  exchanged  between 
activities;  and  the  data  and/or  information  exchanged  with  other  activities  that  are  outside  the 
scope  of  the  model  (i.e.,  external  exchanges).  The  Activity  Model  captures  the  activities 
performed  in  a  business  process  or  mission  and  their  Inputs,  Controls,  Outputs,  and  Mechanisms 
(ICOMs).  Mechanisms  are  the  resources  that  are  involved  in  the  performance  of  an  activity.  The 
objective  behind  the  Operational  Activity  Model  is  development  of  several  small,  quick-to- 
develop  models  rather  than  a  large,  many-layered  model  that  may  be  cumbersome  to  use  and 
time-consuming  to  develop.  The  Activity  Model  generally  includes  a  chart  of  the  hierarchy  of 
activities  covered  in  the  model. 

In  Figure  3-Ib,  the  Detect/Control/Engage  paradigm  was  introduced.  This  is  a  first-level 
decomposition  of  the  conceptual  solution  shown  in  Figure  3-la  and  allows  organization  of  the 
standard  operational  activities  associated  with  the  mission  into  a  second-level  hierarchy.  The 
standard  operational  activities  are  taken  from  the  Universal  Joint  Task  List  (UJTL)  and  the 
Services-derived  task  lists.  The  Detect/Control/Engage  paradigm  is  not  part  of  the  UJTL;  it  is  an 
organizing  principle  related  to  the  mission.  Table  3-1  illustrates  a  reasonable  grouping  of 
activities  against  the  Detect/Control/Engage  model.  For  illustrative  purposes,  a  minimal  set  of 
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operational  activities  was  chosen.  These  activities  provide  the  next  level  of  detail  regarding  what 
must  be  done,  but  they  do  not  provide  any  design  details  except  one:  it  is  envisioned  that  a 
missile  will  fly  into  the  Battlespace  to  engage  the  target. 


Table  3-1 

NCW  Operational  Activity  Model  (OV-5)  Using  Detect/Control/Engage  Hierarchy 


Detect 

Control 

Engage 

•  Search 

•  Detect  target 

•  Detect  environment 

•  Identify  target 

•  Geolocate  target 

•  Nominate  target 

•  Issue  fire  order 

•  Execute  fire  order 

•  Weapon  fly  out 

Referring  once  again  to  the  conceptual  solution  shown  in  Figure  3- la,  it  should  be  clear  that  the 
use  of  the  Detect/Control/Engage  paradigm  provides  the  ability  to  align  most  of  the  activities 
associated  with  the  mission  depicted  in  that  graphic.  What  should  also  be  clear,  though,  is  that 
the  command  authority  for  many  of  the  mission  participants  is  not  illustrated.  Understanding  the 
Organizational  Relationships  for  the  mission  is  critical  to  determining  if  the  architecture  can 
support  mission  execution.  Accordingly,  the  Detect/Control/Engage  paradigm  should  be 
expanded  to  include  Command  as  well.  Table  3-2  adds  Command  to  this  paradigm  and  identifies 
the  activities  associated  with  that  element  of  the  paradigm. 


Table  3-2 

NCW  Operational  Activity  Model  (OV-5)  Using 
Detect/Control/Engage/Command  Hierarchy 


Detect 

Control 

Engage 

Command 

•  Search 

•  Detect  target 

•  Detect 
environment 

•  Identify  target 

•  Geolocate  target 

•  Nominate  target 

•  Issue  fire  order 

•  Execute  fire  order 

•  Weapon  fly  out 

•  Update  mission  plan 

•  Deconflict  airspace 

•  Grant  permission  to 
fire 

Once  the  activities  of  the  NCW  mission  operational  concept  have  been  grouped  in  accordance 
with  the  Activity  Model,  the  key  Information  Elements  (lEs)  that  support  those  activities  can  be 
identified.  This  is  a  critical  step  in  determining  whether  or  not  the  information  exchange 
requirements  associated  with  the  NCW  operational  concept  can  be  supported  by  the  architecture. 
Table  3-3  shows  the  IE  outputs  for  the  NCW  mission  previously  introduced  in  Figure  3-la  at 
each  level  of  the  hierarchy  addressed  in  the  Activity  Model. 

It  should  be  noted  that  choosing  a  different  operational  and  system  solution  for  the  mission  will 
not  generally  change  the  operational  activities  and  key  IE  outputs  identified  in  Tables  3-2  and  3- 
3.  For  example,  suppose  the  customer  chose  to  use  an  Electromagnetic  Countermeasures  (ECM) 
solution  rather  than  using  a  missile.  In  that  case,  electromagnetic  waves  would  penetrate  the 
Battlespace  instead  of  a  missile.  The  operational  activities  would  not  be  changed  by  choosing  an 
ECM  solution,  but  meanings  or  interpretations  of  activities  could  be  changed.  For  example, 
employing  active  ECM  might  cause  “Deconflict  airspace”  to  mean  “Deconflict  EMI  with 
friendly  electronic  equipment.”  The  ECM  solution  provides  an  example  of  attacking  the  target’s 
cyberspace  rather  than  the  target  itself 
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Table  3-3 

Key  IE  Outputs  to  Activities 


Operational  Activity 

IE  Outputs 

Operational  Command 

■  Collection  plan  ■  Permission  to  fire 

■  Weapon  Target  Plan 

Detect 

■  Sensor  reports 

-  Target  detections  and  features 

-  Environment  detections  and  features 

Control 

■  Target  nomination  ■  Fire  order 

-  Fire  control  solution 

Engage 

■  Weapon  launch  report  ■  Effects  on  target* 

*  While  effects  on  the  target  are  an  important  output  of  the  Engage  activity,  they  are  not  an  information  element. 


While  grouping  the  aetivities  from  the  Figure  3- la  operational  eoncept  into  the 
Detect/Control/Engage/Command  hierarchy  does  offer  some  level  of  organization  of  the 
operational  activities,  it  fails  to  provide  a  sense  of  activity  flow.  The  activity  flow  will  be 
discussed  later  in  this  chapter,  but  it  should  be  noted  here  that  the  flow  is  rooted  in  the  logical 
relations  between  the  activities.  The  logical  relations  between  activities  provide  a  starting  point 
for  understanding  activity  flow.  Figure  3 -4a  illustrates  the  simple  logical  relations  between  the 
three  high-level  activities;  in  other  words,  it  shows  the  input/output  relationships.  In  contrast  to 
the  simple  one-to-one  relation  shown  in  Figure  3 -4a,  Figure  3 -4b  illustrates  how  activities  (in  the 
second  level  relations)  can  exist  in  a  one-to-many  relationship.  The  dashed  line  in  the  graphic 
indicates  that  relations  between  activities  can  occur  that  were  not  envisioned  in  the  activity 
model.  An  example  of  this  type  of  dotted-line  relationship  would  be  the  detection  of  a  target  in 
the  presence  of  clutter  or  other  interfering  signals. 


Figure  3-4b.  Example  of  Second-Level  Relations 


Figure  3-4.  Logical  Relations  among  Activities 
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The  logical  relations  of  the  activity  model  can  he  illustrated  through  the  use  of  an  Operational 
Node  Connectivity  Description  (OV-2)  view,  which  is  described  next  in  this  chapter. 

Operational  Node  Connectivity  Description  (OV-2) 

Before  Operational  Node  Connectivity  Description  can  be  addressed,  it  is  important  to  recall 
what  an  Operational  Node  actually  is.  An  Operational  Node  is  a  collection  of  one  or  more 
activities  that  operates  under  a  single  authority,  produces  one  or  more  outputs,  and  interacts  with 
other  Operational  Nodes.  Figure  3-5  provides  an  illustration  of  an  Operational  Node 
Connectivity  Description  Diagram  that  shows  the  logical  relations  of  a  high-level  activity  model 
in  which  each  first-level  activity  is  treated  as  a  node.  The  nodal  relations  are  established  by 
exchange  of  IBs  and  do  not  necessarily  imply  Organizational  Relationships. 

In  order  for  the  Operational  Node  Connectivity  Description  view  to  be  useful  in  showing  how 
activities  under  the  control  of  a  single  authority  are  integrated  with  each  other  and  how  the  node 
itself  interacts  with  other  nodes,  it  is  critical  to  adopt  a  uniform  nodal  activity  model.  While  the 
Detect/Control/Engage  model  calls  out  three  distinct  nodes  of  the  conceptual  solution  in  Figure 
3- la,  it  does  not  provide  a  model  of  what  is  happening  inside  the  node.  Each  of  the  nodes  in 
Table  3-2  clearly  has  a  different  purpose  and  different  activities  to  be  performed.  A  uniform 
nodal  model  would  provide  an  organization  of  the  operational  activities  in  ways  that  allow  easy 
assemblage  of  OV-2  nodes  into  an  architecture.  The  significance  of  this  subtle  point  may  not  be 
obvious  when  there  are  only  three  nodes  (e.g.,  Detect/Control/Engage)  to  be  instantiated.  When 
there  are  dozens,  or  hundreds,  or  even  thousands  of  nodes  in  a  complex  FoS,  however,  the 
uniform  internal  organization  of  the  nodes  will  dramatically  affect  whether  the  nodes  can  be 
easily  “assembled”  (i.e.,  be  integrated  together  and  be  made  interoperable). 


Figure  3-5.  Operational  Node  Connectivity  Description  Diagram  (OV-2)  for  Precision 
Engagement  Example 

Figure  3-6  illustrates  a  nodal  model  that  can  be  used  uniformly  across  the  architecture.  The 
specific  nodal  capability  identified  in  the  graphic  will  determine  the  activities  performed  for  the 
node.  The  DoD  Architecture  Framework  views  the  OV-2  nodes  as  bundles  of  activities;  in  other 
words,  the  nodal  activity  model  for  “Detect”  would  include  all  of  the  activities  associated  with 
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that  overarching  activity.  Mission  capabilities  can  also  be  treated  as  overarching  nodes.  Figure  3- 
6  adds  to  this  concept  by  providing  the  layers,  including  services  and  physical  assets,  through 
which  the  node  is  instantiated.  In  this  case,  the  model  for  the  specific  warfare  capability  of 
Precision  Engagement  would  be  the  center  (the  Operational  Activity  Model).  The  Precision 
Engagement  node  would  then  decompose  into  the  four  nodes  shown  in  the  hierarchy  in  Table  3-2. 


Figure  3-6.  Uniform  Nodal  Model 

The  logical  relations  of  the  Nodal  Activity  Model  depend  in  large  part  on  the  Organizational 
Relationships  established  for  the  mission.  These  relationships  are  described  in  the  Organizational 
Relationships  Chart  (OV-4)  view. 

Organizational  Relationships  Chart  (OV-4) 

The  Organizational  Relationships  Chart  (OV-4)  illustrates  the  relationships  among  organizations 
or  resources  in  an  architecture.  These  relationships  can  include  command,  control,  and 
coordination  relationships  (which  influence  what  connectivity  is  needed)  as  well  as  many  others, 
depending  upon  the  purpose  of  the  architecture.  It  is  important  to  include  these  relationships  in 
an  operational  view  of  an  architecture  because  they  illustrate  fundamental  roles  and  management 
relationships. 
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NCW  can  achieve  mission  effectiveness  through  the  irmovative  use  of  command  and  control 
(C^).  Figure  3-7  shows  that  the  military  force  in  this  architectural  description  will  operate  at  the 
tactical  level  and  he  under  ultimate  control  of  the  Theater  Commander.  How  the  Theater 
Commander  allocates  command  authority  to  the  individual  systems  or  SoS  commanders  will 
significantly  affect  how  the  military  force  fights  and  its  ability  to  achieve  speed  of  effects  in  the 
Battlespace.  Figure  3-7  illustrates  a  possible  C^  concept  that  could  be  used  for  this  NCW  mission. 

Command  relationships  for  NCW  missions  can  vary  from  highly  centralized  control  to  command 
by  negation.  The  operational  situation  will  determine  the  appropriate  command  structure.  For 
example,  in  a  conflict  with  heightened  political  consequences,  it  may  be  more  appropriate  to 
have  centralized  command.  From  the  perspective  of  developing  an  architecture  to  support  the 
mission,  it  is  critical  to  identify  the  organizational  relationships,  because  each  command  structure 
will  have  differing  needs  for  information  and  communications  support.  These  needs  must  be 
understood  in  order  to  develop  an  architecture  that  will  be  effective  in  accomplishing  the 
mission.  Figure  3 -7a  shows  the  hierarchy  of  command  relations  for  this  case  study. 

The  matrix  of  command  relations  provided  in  Figure  3 -7b  is  the  first  architectural  artifiact  that 
illustrates  the  nodal  model  of  the  OV-2  node  as  having  command  relationships  in  a  structured 
control  construct  (i.e.,  each  node  has  a  single  point  of  entry  for  control).  For  example,  the 
command  and  control  (through  the  Theater  Commander)  that  enters  through  the  Operational 
Command  node  and  exits  through  the  Control  and  Engage  node  shows  that  the  Operational 
Commander  is  under  the  control  of  only  one  superior  node.  These  entry  and  exit  points  are  also 
the  first  high-level  descriptions  of  the  lines  of  communication. 

The  architectural  products  introduced  thus  far  to  describe  the  Operational  Concept  (the  High- 
Level  Operational  Concept  Graphic,  the  Operational  Activity  Model,  the  Operational  Node 
Connectivity  Description  Diagram,  and  the  Organizational  Relationships  Chart)  enable  the 
systems  architect  or  engineer  to  move  from  an  operational  mission  concept  to  a  structured, 
controlled  construct  for  meeting  the  mission  objectives.  Essentially,  during  the  construction  of 
the  Operational  Concept  views,  the  systems  architect  develops  a  collection  of  Operational  Nodes 
through  which  the  mission  will  be  executed.  What  none  of  the  previously  introduced  products 
provide  is  a  means  for  determining  the  executability  or  dynamic  validity  of  this  operational  view 
of  the  architecture.  The  Operational  Event/Trace  Description  (OV-6c)  provides  this  capability. 


Figure  3-7a  Hierarchy  of  Command  Relations 
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Node  m  is _ to  Node  n  (m  =  row,  n  =  column) 

Sp  =  Superior 

P  =  Peer 

Sb  =  Subordinate 

-  =  No  direct  relationship  (i.e.,  no  nodal  connectivity) 

"igure  3-7b.  Matrix  of  Command  Relations 

Figure  3-7.  Organizational  Relationships  Chart  (OV-4)  for  Precision  Engagement  Example 
Operational  Event/Trace  Description  (OV-6c) 

Operational  activities  should  result  in  accomplishment  of  the  mission  objective,  or  causation  of 
the  desired  effect  in  the  Battlespace.  The  Operational  Event/Trace  Description  enables  traceability  of 
actions  in  a  scenario  or  critical  sequence  of  events  so  the  architect  can  determine  if  the  activities 
will,  in  fact,  deliver  the  desired  result.  Basically,  it  introduces  timing  and  sequence  into  the 
Operational  Activity  Model.  An  Operational  Event/Trace  Description  (OV-6c)  is  provided  in 
Figure  3-8. 

The  Operational  Event/Trace  Description  can  also  be  organized  into  Nodal  Model  activities 
using  the  Operational  Node  Connectivity  Description  (OV-2)  and  the  Organizational 
Relationships  Chart  for  control  (or  triggering)  of  architecture  responses  to  scenario  events.  This 
organization  of  the  Operational  Event/Trace  Description  is  shown  in  Figure  3-9.  Note  that  the 
“Update  Mission  Plan”  activity  must  be  visited  twice,  first  when  the  “trigger”  from  the  “Issue 
Task  Order  and  Guidance”  starts  the  execution  sequence  and  again  when  a  target  is  nominated.  If 
Battle  Damage  Assessment  were  included  in  the  execution  sequence,  “Update  Mission  Plan” 
would  in  fact  be  revisited  a  third  time. 
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Figure  3-8.  Operational  Event/Trace  Description  (OV-6c)  for  Precision  Engagement  Example 
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Figure  3-9.  Operational  Event/Trace  Nodal  Description  (OV-6c) 
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Operational  Information  Exchange  Matrix  (OV-3) 

The  Operational  Node  Connectivity  Description  Diagram  (OV-2)  can  be  used  to  create  a  nodal 
version  of  the  Operational  Event/Trace  Description  (OV-6c)  using  an  Operational  Information 
Exchange  Matrix  (OV-3).  This  view  traces  the  operational  activities  to  operational  nodes  along 
with  their  associated  lEs.  The  Architecture  Framework  defines  the  lERs  of  the  Operational 
Information  Exchange  Matrix  (OV-3)  view  as  the  relationship  among  three  basic  entities 
(activities,  operational  nodes,  and  information  flow)  of  the  operational  view  of  the  architecture. 
Using  the  sample  architecture  for  NCW  engagement  illustrated  in  Figure  3-8  and  the  information 
elements  for  the  Operational  Activity  Model  provided  in  Table  3-3,  it  is  possible  to  build  a 
sample  lER  matrix,  which  is  displayed  in  Table  3-4.  Because  the  Operational  Information 
Exchange  Matrix  displays  exchanges  between  the  operational  nodes  of  the  Operational  Node 
Connectivity  Description  (OV-2),  the  groupings  and  connections  of  the  OV-2  cause  a 
reorganization  of  the  outputs  of  the  Operational  Activity  Model  (OV-5)  that  were  previously 
illustrated  in  Table  3-3.  In  the  representation  of  the  OV-3  provided  in  Table  3-4,  each  need  line 
of  the  OV-2  is  represented  by  a  line  (or  table  entry). 

Table  3-4 


Operational  Information  Exchange  Matrix  (OV-3)  for  Precision  Engagement  Example 


Source 

OV-2  Node 

Nodal 

Activity 

Information 

Element 

Receiving 
OV-2  Node 

Theater  Command 

Issue  Task  Order  and 
Guidance 

Task  Order  and 
Guidance 

Operational 

Command 

Operational  Command 

Update  Mission  Plan 

Collection  Plan 

Detect 

Update  Mission  Plan 

Weapon  Target  Plan 

Control 

Grant  Permission  to  Fire 

Permission  to  Fire 

Control 

Detect 

Detect  Target 

Sensor  Reports 

Control 

Detect  Environment 

Sensor  Reports 

Control 

Control 

Nominate  Target 

Target  Nomination 

Operational 

Command 

Issue  Fire  Order 

Fire  Order 

Engage 

Engage 

Execute  Fire  Order 

Weapon  Launch 
Report 

Operational 

Command 

Operational  Concept  Summary 

Once  the  OV-6c  nodal  description  is  developed,  the  systems  architect  will  for  the  first  time  have 
both  the  activities  and  the  information  flow  identified  so  that  the  high-level  operational  concept 
introduced  in  the  OV-1  can  actually  be  understood  from  an  architectural  perspective.  This 
product  connects  the  end-to-end  execution  of  activities  to  mission  capability,  so  it  automatically 
provides  a  mission  capability  tracking  function.  It  must  be  noted,  however,  that  at  this  time,  no 
physical  solution  has  been  assumed.  Physically  instantiating  the  operational  concept  comprises 
the  next  steps  in  the  process. 
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System  Functional  Mapping 

With  the  completion  of  the  Operational  Concept  views,  the  systems  architect  or  engineer  is  now 
in  a  position  to  do  the  actual  systems  engineering  against  a  more  rigorously  defined  operational 
concept.  This  systems  engineering  begins  with  System  Functional  Mapping.  Due  to  the 
complexity  of  the  FoSs  of  interest,  simply  keeping  track  of  the  data  describing  the  systems,  their 
relationships,  and  their  evolution  is  an  overwhelming  task.  System  Functional  Mapping  of  the 
solution  provides  a  stable  model  that  facilitates  the  management  of  the  data  describing  the 
systems,  their  relationships,  and  their  evolution  as  well  as  the  mapping  of  systems  to  functions. 
The  NCW  System  Functional  Mapping  can  be  described  using  three  architecture  product  series: 

•  Systems  Functionality  Description  (SV-4)  series 

•  Operational  Activity  to  Systems  Function  Traceability  Matrix  (SV-5) 

•  Systems-to-Systems  Matrix  (SV-3)  series,  which  includes  the  Systems  to  Systems  Functions 
Mapping  (SV-3a),  the  Operational  Activities  to  Systems  Traceability  Matrix  (SV-3b),  and 
the  Systems^  Matrix  (SV-3c) 

Each  product  series  and  its  use  in  an  abstract  NCW  context  are  described  in  the  following 
paragraphs. 

Systems  Functionality  Description  (SV-4)  Series 

The  functions  and  primary  data  flow  between  functions  required  to  support  operational  concepts 
are  presented  in  the  System  Functionality  Description  (SV-4),  which  is  applicable  to  a  broad 
spectrum  of  mission  capability  architectures  including  Theater  Air  Missile  Defense  (TAMD), 
Strike,  Undersea  Warfare,  Information  Operations,  Counter  Terrorism,  Expeditionary  Warfare, 
Navigation,  Battle  Force  Command  and  Control,  and  Intelligence,  Surveillance,  and 
Reconnaissance.  The  System  Functionality  Description  (SV-4)  series  includes  the  High-Level 
Systems  Functions  List  (SV-4a),  Systems  Functional  View  (SV-4b),  and  Logical  Interface  View 
(SV-4c).  The  High-Level  Systems  Functions  List  is  presented  in  the  following  paragraph,  but  it 
is  followed  by  a  description  of  the  Operational  Activity  to  Systems  Function  Traceability  Matrix 
(SV-5).  While  the  SV-5  is  not  part  of  the  SV-4  series,  it  is  presented  in  the  middle  of  the  SV-4 
series  because  this  order  reveals  the  logical  flow  of  the  products.  Following  the  discussion  of  the 
SV-5,  the  Systems  Functional  View  (SV-4b)  and  Logical  Interface  View  (SV-4c)  are  presented. 

In  discussing  the  High-Level  Systems  Functions  List  (SV-4a),  it  is  important  to  note  that  each  of 
the  nodal  activities  of  the  Precision  Engagement  model  will  involve  performance  of  four  high- 
level  system  functions: 

•  Sense 

•  Command 

•  Act 

•  Interoperate 

The  first  three  directly  enable  operational  activities,  but  the  last  one  is  primarily  related  to  the 
exchange  of  information  and  services  between  operational  nodes.  Table  3-5  provides  definitions 
for  the  first-level  system  functions.  The  second  level  functions  will  also  be  needed  to  describe 
how  the  systems  will  support  the  activity  models  shown  for  the  Operational  Event/Trace 
Description  (OV-6c,  shown  previously  in  Figures  3-8  and  3-9). 
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Table  3-5 


High-Level  Systems  Functions  List  (SV-4a) 


First-Level 

Functions 

Definitions 

Sense 

Functions  that  perform  detection  and  identification  of  objects  in  the  area  of 
interest  and  develop  imagery,  track,  and  parametric  data  on  these  objects; 
involves  receipt  of  data  from  objects  outside  the  system  that  provide  the  system 
with  knowledge/data  regarding  these  objects  outside  the  system;  includes  fusion 
of  data  from  multiple  sources  to  create  a  common  sensor  picture  of  the  area  of 
interest;  could  be  receipt  of  a  signal  or  receipt  of  an  emission 

Command 

Functions  that  support  and  perform  decision-making  processes  that  effectively 
and  efficiently  direct  the  force(s)  under  command  and  that  support  the 
employment  of  offensive  and  defensive  weapons;  involves  communication  of 
an  executable  order;  requires  output  of  Process  (to  create  the  order)  and  use  of 
Interoperate  (to  transmit  the  order) 

Act 

Functions  necessary  to  deploy,  maneuver,  sustain,  and/or  configure  platforms, 
troops,  cargo,  sensors,  and  weapons  and  to  execute  engagements;  a  physical 
response  to  a  command  (e.g.,  change  the  state  of  a  switch;  launch  a  weapon; 
transmit  data);  can  be  thought  of  as  “actuation” 

Interoperate 

Functions  that  support  data  dissemination,  including  formatting,  access,  and 
routing  of  data  to  and  between  all  other  functions;  also  includes  the 
development  and  dissemination  of  common  reference  time,  navigation,  and 
METOC  data;  additionally,  includes  all  communication  functions 

Operational  Activity  to  Systems  Function  Traceability  Matrix  (SV-5) 

Figure  3-10  provides  a  high-level  operational  aetivity  to  system  funetion  traceability  matrix  (SV- 
5).  It  traces  the  enabling  of  operational  activities  by  system  functions.  The  Sense  function 
enables  the  Detect  activity.  It  should  be  noted  that  the  Sense  function  in  the  Precision 
Engagement  example  is  done  at  the  FoS  level  and  requires  the  use  of  multiple  sensors.  The  Act 
function  is  related  to  physical  response,  and  the  Command  function  is  related  to  decision-making 
and  planning.  The  Interoperation  function  connects  the  high-level  activity  nodes  and  supports  the 
issuance  of  orders.  Figure  3-10  illustrates  the  case  for  the  Precision  Engagement  example  in 
which  each  of  the  three  high-level  activities  is  treated  as  a  separate  node  based  on  the  specific 
nodes  of  the  Operational  Node  Connectivity  Description  (OV-2)  illustrated  previously  in  Figure  3-5. 


Enabling  System  Function 

Operational  Activity 

Detect 

Control 

Engage 

Sense 

V 

V 

Command 

Act 

V 

Interoperate* 

V 

Figure  3-10.  Operational  Activity  to  Systems  Function  Traceability  Matrix  (SV-5) 

*  The  interoperation  in  this  model  is  based  on  the  OV-2  description  that  makes  each  element  of  the  Detect-Control- 
Engage  hierarchy  a  separate  node. 
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The  SV-5  must  be  expanded  to  the  next  level  of  decomposition  in  order  to  understand  why  the 
Sense  function  supports  both  the  Detect  and  Control  activities.  Table  3-6  shows  the  System 
Functionality  Description  (SV-4)  and  Operational  Activity  to  System  Function  Traceability 
Matrix  (SV-5)  level  of  detail  necessary  to  relate  the  systems  functions  to  the  second-level 
operational  activities  presented  in  the  Operational  Event/Trace  Description  (OV-6c). 
Additionally,  Chapter  7  provides  an  example  of  a  more  detailed  SV-4  and  SV-5. 


Table  3-6 

Lower-Level  Operational  Activities  and  System  Functions  for  the  Operational  Activity  to 
_ Systems  Function  Traceability  Matrix  (SV-5) _ 


OV-2 

Node 

Operational 

Activity 

System 

Function 

Nodal 

IE 

Operational 

Command 

Update  mission 
plan 

Command 

Weapon  target 
association 

Weapon  target  plan 

Collection  options 

Collection  plan 

Deconflict 

airspace 

Air  picture  integration 

Collection  plan* 

Grant  permission 
to  fire 

Decision  support 

Permission  to  fire 

Communication  of  order 

Detect 

Search 

Sense 

Passive  search 

Sensor  reports 

Detect 

•  Target 

•  Environment 

Single  sensor  sense 

Control 

Geolocate  target 

Sense 

Multi-sensor  sense  (data 
alignment  &  association) 

Fire  Control 

Solution 

ID  target 

Feature  extraction 

Nominate  target 

Command 

Decision  support 

Target  nomination 

Issue  Fire  Order 

Generate  order 

Fire  Order 

Engage 

Execute  Fire 

Act 

Weapon  initialization  and 

Weapon  launch 

Order 

launch 

report 

Weapon  Fly  Out 

Weapon  Guidance 

Battlespace  Effect** 

^Collection  plan  is  updated  for  deconfliction. 

**While  Battlespace  effects  are  an  important  output  of  the  Engage  node,  they  are  not  an  IE. 


Systems  Functionality  Description  (SV-4)  Series  (Continued) 

Returning  to  the  Systems  Functionality  Description  (SV-4)  series,  the  next  product  is  the 
Systems  Functional  View  (SV-4b),  which  depicts  the  logical  relations  of  the  first-level  functional 
decomposition.  These  functions  were  previously  defined  in  Table  3-5.  The  first  level  includes  the 
highest  order  functions:  Sense  (blue).  Command  (red).  Act  (green),  and  Interoperate  (gold). 
Figure  3-11  can  be  derived  from  the  Operational  Node  Connectivity  Description  Diagram  (OV-2) 
shown  previously  in  Figure  3-5  by  applying  the  Operational  Activity  to  System  Function 
Traceability  Matrix  (SV-5,  shown  in  Figure  3-10)  to  the  activities. 

The  final  Systems  Functional  Description  product  is  the  Logical  Interface  View  (SV-4c), 
presented  in  Figure  3-12.  The  Logical  Interface  View  presents  the  information  elements  for  the 
logical  interfaces  between  the  system  functions.  This  view  is  used  primarily  in  the  second  order 
analysis  to  assess  completeness  as  well  as  deficiencies  in  integration  and  interoperability.  This 
view  is  derived  from  the  logical  relations  of  the  Systems  Functional  View  (SV-4b,  Figure  3-11) 
and  the  Operational  Event/Trace  Nodal  Description  (OV-6C,  Figure  3-9)  using  the  Operational 
Activity  to  System  Function  Traceability  Matrix  (SV-5,  Figure  3-10). 
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Operational 


Legend: 


Activity 


Operational  Activities  Function  |  System  Functions 


Figure  3-11.  Systems  Functional  View  (SV-4b)  for  the  Precision  Engagement  Example 


Operational 


Activity 


Legend: 


Operational  Activities  function  |  System  Functions 


Figure  3-12.  Eogical  Interface  View  (SV-4c)  for  the  Precision  Engagement  Example 
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Systems-to-Systems  Matrix  (SV-3) 

The  Systems-to-Systems  Matrix  (SV-3)  is  more  useful  for  FoS  systems  engineering  when  the 
Architecture  Framework  is  revised  to  include  three  views: 

•  SV-3a:  Systems  to  Functions  Matrix 

•  SV-3b:  Operational  Activity  to  Systems  Traceability  Matrix 

•  SV-3c:  Systems^  Matrix 

The  SV-3a  is  a  matrix  that  summarizes  which  individual  physical  systems  are  used  to  enable 
which  individual  system  functions.  Each  cell  of  the  matrix  points  to  a  functional  use  case  of  the 
physical  systems.  Using  the  systems  functions  along  with  the  Operational  Activity  to  Systems 
Function  Traceability  Matrix  (SV-5),  the  Systems  to  Functions  Matrix  provides  the  direct 
traceability  of  operational  capabilities  into  the  physical  systems  of  the  FoS.  This  results  in  a 
matrix  (the  Operational  Activity  to  Systems  Traceability  Matrix  (SV-3b))  that  is  analogous  to  the 
Operational  Activity  to  Systems  Function  Traceability  Matrix  but  at  the  physical  level.  Each  cell 
of  the  Operational  Activity  to  Systems  Traceability  Matrix  points  to  an  operational  use  case  of 
the  physical  systems.  The  Systems^  Matrix  is  in  the  form  of  the  Framework’s  Systems^  Matrix, 
but  in  this  methodology,  it  is  built  using  the  relations  between  system  functions  provided  by  the 
Systems  Functional  View  (SV-4b).  The  logical  interfaces  of  the  Eogical  Interface  View  (SV-4c) 
taken  with  the  Systems^  Matrix  can  be  used  to  begin  building  a  physical  instantiation  of  the 
Operational  Information  Exchange  Matrix.  Each  of  the  three  Systems  Matrix  views  is  described 
in  the  following  paragraphs. 

The  Systems  to  Systems  Functions  Mapping  must  be  introduced  at  this  point  to  describe  an  FoS 
that  can  enable  the  system  functions.  An  abstract  approach  following  the  concepts  of  Figure  3-2 
can  be  used  as  a  high-level  description  based  on  five  principal  types  of  systems: 

•  Networks 

•  Sensors 

•  Processors 

•  Weapons 

•  Platforms 

This  organization  of  the  systems  does  have  some  overlap,  especially  at  the  SoS  level.  For 
example,  most  networks,  sensors,  and  weapons  have  some  form  of  an  embedded  processor.  Also, 
many  weapons  have  sensors.  However,  at  the  FoS  level,  the  decomposition  of  the  FoS  into  the 
five  types  is  useful. 


The  Systems  to  Systems  Function  Matrix  (SV-3a),  depicted  at  a  high  level,  would  take  the  form 
illustrated  in  Figure  3-13.  In  this  context,  platforms  are  systems  with  the  function  of  carrying  and 
positioning  networks,  sensors,  processors,  and  weapons. 


Enabling  System 

System 

Function  I 

Sense 

Command 

Act 

Interoperate 

Networks 

Sensors 

Processors 

Weapons 

Platforms 

Figure  3-13.  High-Level  Systems-to-Systems  Function  Matrix  (SV-3a) 
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Using  the  Systems-to-Systems  Function  Matrix  (SV-3a,  shown  in  Figure  3-13)  and  the 
Operational  Activity  to  Systems  Function  Traceability  Matrix  (SV-5,  shown  previously  in  Figure 
3-12),  it  is  a  straightforward  exercise  to  derive  the  Operational  Activity  to  System  Traceability 
Matrix  (the  SV-3b,  shown  in  Figure  3-14).  In  order  to  fully  understand  how  the  enabling  systems 
interoperate  with  each  other  and  are  used  as  an  FoS  to  enable  mission  capabilities,  the  activities 
(from  the  Operational  Activity  Model  (OV-5))  need  to  be  grouped  into  nodes  that  will  establish 
natural  lines  of  communication  between  physical  locations.  Creating  these  groupings  is  one  of 
the  purposes  of  the  Operational  Node  Connectivity  Description  (OV-2). 


Enabling  System 

Operational  Activity 

Detect 

Control 

Engage 

Sensor 

Processor 

Weapon 

Figure  3-14.  Operational  Activity  to  Systems  Tracea 

Dility  Matrix  (SV-3b) 

2 

The  Architecture  Framework  represents  the  SV-3  as  the  Systems  Matrix,  which  is  a  description 
of  the  system-to-system  relationships  identified  in  the  intemodal  and  intranodal  perspectives  of 
the  System  Interface  Description.  The  Systems^  Matrix,  which  has  been  denoted  in  this  book  as 
the  SV-3c,  is  the  first  high-level  exhibit  of  FoS  systems  interoperation.  Specifically,  it  displays 
which  systems  interoperate  with  each  other.  This  information  cannot  be  derived  directly  from  the 
previous  architecture  views.  Strictly  speaking,  the  Systems^  Matrix  needs  to  be  derived  from  use 
cases  or  threads  in  the  Operational  Concept  that  show  execution  sequences  enabled  by  systems, 
connectivity,  and  operational  command  relations.  This  need  can  be  clearly  seen  if  a  high-level 
Systems^  Matrix  is  constructed  for  the  system  types  used  in  the  Systems  to  Systems  Functions 
Mapping  (SV-3a).  Figure  3-15  illustrates  the  Systems^  Matrix  at  a  high  level. 


Sensors 

Processors 

Weapons 

Si 

S2 

Pi 

P2 

W 

Sensors 

Si 

- 

- 

V 

- 

S2 

- 

V 

- 

Processors 

Pi 

- 

P2 

Weapons 

W 

2 

Figure  3-15.  Systems  Matrix  (SV-3c)  for  Precision  Engagement  Example 

System  Interface  Mapping 

System  interface  mapping  can  be  supported  through  the  use  of  six  Framework  products: 

•  Operational  Node  Connectivity  Description  (OV-2) 

•  Operational  Information  Exchange  Matrix  (OV-3) 

•  Systems  Interface  Description  (SV-1) 

•  System  Communications  Description  (SV-2) 

•  Technical  Standards  Profile  (TV-1) 

•  System  Data  Exchange  Matrix  (SV-6) 
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It  may  be  helpful  to  think  of  each  of  the  system  interface  mapping  Architecture  Framework 
products  as  circuit  cards  that  can  be  inserted  into  an  operational  context  to  provide  ever- 
increasing  levels  of  clarity  regarding  the  mission  capability  achievable  considering  the  activities, 
functions,  systems,  and  connectivity  either  currently  achievable  or  planned  for  the  future.  As 
these  “circuit  cards”  are  inserted,  the  architect,  engineer,  or  acquisition  specialist  can  acquire  a 
snapshot  of  the  mission  capability  of  the  FoS  that  includes  consideration  and  reflection  of 
multiple  layers  of  interoperability  and  offers  a  more  realistic  perspective  of  the  capabilities  of  an 
FoS  as  well  as  facilitated  identification  of  critical  gaps  in  that  capability.  The  system  use  case 
section  that  follows  this  paragraph  illustrates  instantiations  of  the  System  Interface  Mapping 
Architecture  Framework  products. 

System  Use  Cases:  the  Instantiated  Operational  Nodes  (OV-2) 

The  logical  activity  model  depicted  by  the  Operational  Node  Connectivity  Description  (shown 
previously  in  Figure  3-5)  can  be  instantiated  (abstractly)  using  the  Operational  Activity  to 
System  Traceability  Matrix  shown  previously  in  Figure  3-14.  Networks  must  also  be  allocated  to 
the  need  lines  of  the  Operational  Node  Connectivity  Description.  These  instantiations  of  the 
nodes  and  the  need  lines  are  essentially  the  development  of  the  System  Interface  Description 
(SV-1)  and  the  System  Communications  Description  (SV-2).  Using  the  Sensor,  Processor, 
Weapon,  and  Network  symbology  introduced  in  Chapter  1,  the  logical  model  illustrated  in 
Figure  3-16  emerges.  This  is  the  earliest  architectural  graphic  that  describes  how  systems  are 
used  to  enable  operational  activities. 


Figure  3-16a.  Systems  Interface  Description  (SV-1) 
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Figure  3- 16b.  System  Communications  Description  (SV-2) 

Figure  3-16.  Abstract  Instantiation  of  the  Operational  Nodes  for  Precision  Engagement  Example 
Systems  Interface  Description  (SV-1) 

The  System  Interface  Description  (SV-1)  associates  physical  systems  with  the  operational  nodes, 
as  illustrated  at  a  high  level  in  Figure  3- 16a.  This  view  is  derived  from  the  Operational  Node 
Connectivity  Description  (OV-2)  and  the  Operational  Activity  to  System  Traceability  Matrix 
(SV-3b).  Following  the  hierarchy  of  Figure  1-4,  two  different  levels  of  processing  have  been 
introduced.  The  first  level  (indicated  as  Pi)  is  used  for  command  and  control.  The  second  level 
(indicated  as  P2)  is  used  for  the  processing  of  sensor  data  for  tactical  purposes  (i.e.,  for  directly 
establishing  the  fire  control  solution  from  sensor  data).  The  command  and  control  processor  and 
network  could  be  expected  to  have  less  stressing  throughput  and  latency  requirements  than  the 
processor  and  network  that  supports  sensing  and  targeting  directly. 

This  instantiation  is  the  Nodal  System  Architecture  of  the  Uniform  Nodal  Model  presented 
previously  in  Figure  3-6.  The  System  Architecture  Services  presented  in  the  Uniform  Nodal 
Model  are  the  System  Functions,  which  are  linked  to  the  Operational  Activity  Model  by  the 
Operational  Activity  to  System  Function  Traceability  Matrix  (SV-5)  and  to  the  Nodal  System 
Architecture  by  the  Systems  Matrix  (SV-3)  series. 

Systems  Communication  Description  (SV-2) 

This  view  represents  the  specific  communications  systems  pathways  or  networks  through  which 
the  physical  nodes  and  systems  interface.  These  pathways  are  illustrated  at  a  high  level  in  Figure 
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3-16b.  Just  as  it  was  for  the  Systems  Interface  Description  (SV-1),  the  Operational  Node 
Connectivity  Description  (OV-2)  is  the  starting  point.  The  Operational  Information  Exchange 
Matrix  (OV-3)  must  also  be  considered,  but  no  previous  views  presented  from  the  Architecture 
Framework  provide  the  communication  systems  or  pathways  to  instantiate  the  need  lines 
between  nodes.  This  instantiation  is  the  Infrastructure  layer  of  the  Uniform  Nodal  Model 
presented  previously  in  Figure  3-6.  The  Interoperation  Services  layer  would  be  described  using 
standards  like  the  Open  System  Interface  (OSI)  model. 

The  System  Communications  Description  (SV-2)  can  also  be  used  to  revise  the  Systems  Matrix 
(SV-3c)  to  reflect  the  communications  systems  pathways  that  provide  nodal  connectivity 
between  systems.  Figure  3-17  modifies  the  uninstantiated  version  of  the  SV-3c  presented 
previously  in  Figure  3-15  to  illustrate  the  nodal  connectivity  at  a  high  level  for  the  Precision 
Engagement  example. 
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Figure  3-17.  Nodal  version  of  Systems  Matrix  (SV-3c) 


The  diagram  in  Figure  3-16  can  be  redrawn  in  the  format  used  in  Figure  1-1,  which  would  yield 
the  diagram  shown  in  Figure  3-18.  Diagrams  like  Figures  3-16  and  3-18,  created  using  the 
supporting  architectural  exhibits  in  this  chapter,  provide  the  first  artifacts  that  demonstrate  the 
logical  validity  of  the  architecture.  In  practice,  when  architects  work  with  users  (in  this  case,  the 
operators  of  the  military  systems),  these  users  can  go  directly  to  a  diagram  like  Figure  3-18,  in  a 
manner  similar  to  that  used  in  the  beginning  of  this  chapter.  It  is,  however,  the  rigor  of  the 
tedious  details  that  lays  the  foundation  for  architectural  assessments,  modeling  and  simulation, 
and  the  disciplined  system  engineering  trades  that  make  architectures  an  engineering  tool.  All  of 
the  previous  “tedious  details”  must  be  rolled  up  into  a  database  that  can  be  used  for 
interoperability  assessments.  This  is  the  purpose  of  our  expanded  view  of  the  Systems  Data 
Exchange  Matrix  (SV-6),  which  is  presented  later  in  this  chapter. 

Technical  Standards  Profile  (TV-1) 

The  Technical  Standards  Profile  represents  the  technical  component  of  the  architecture  in 
providing  a  set  of  rules  that  governs  system  implementation  and  operation.  In  this  sense,  the 
Technical  Standards  Profile  should  include  more  than  just  interface  standards  and  protocols.  In 
practice,  however,  the  profile  frequently  provides  only  the  list  of  standards  and  protocols 
associated  with  the  transport  layer  of  interfacing  and  communications  between  systems.  This 
weakness  is  addressed  in  the  Framework  2.0,  which  includes  a  notional  example  of  a  Technical 
Standards  Profile  that  addresses  service  areas,  services,  and  standards  that  go  beyond  interfaces. 
It  may  therefore  be  appropriate  to  decompose  the  profile  into  standards  that  align  with 
overarching  accepted  standards  like  the  Open  System  Interface  (OSI)  standard. 
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Figure  3-18.  Combined  Systems  Interfaee  Description  (SV-1)  and  System  Communications 
Description  (SV-2)  for  Precision  Targeting  Example  Using  Centralized  C^  and  Distributed 
Execution  (Instantiated  OV-2) 


At  the  level  of  abstraction  in  Figure  3-16,  it  is  difficult  to  provide  abstractions  of  the  rule  sets; 
however,  it  is  possible  to  give  examples  of  the  types  of  standards  currently  being  used.  Within 
the  Technical  Standards  Profile,  logical  standards  are  associated  with  the  information  elements 
being  exchanged  (data)  and  the  system  function  (application)  processing  the  data.  Information 
element  standards  govern  the  format  of  the  data  being  exchanged.  Examples  of  standards  for 
information  elements  include  MIL-STD-6016  for  J-series  bit-oriented  messages;  MIL-STD-601 1 
for  M-series  bit-oriented  messages;  Joint  Publication  604  for  U.S.  Message  Text  Format 
(USMTF)  character-oriented  messages;  and  Imagery  formats  such  as  GIF  or  JPEG.  System 
functions  are  enabled  by  applications  defined  at  an  appropriate  level  of  abstraction  or 
decomposition  necessary  for  the  architect  to  solve  the  problem.  Some  examples  of  system 
function  standards  include  Defense  Information  Infrastructure  Common  Operating  Environment 
(DII  COE)  correlation  services.  Simple  Mail  Transport  Protocol  (email),  and  Simple  Network 
Management  Protocol.  Chapter  4  will  provide  further  details  on  the  Technical  Standards  Profile. 


Systems  Data  Exchange  Matrix  (SV-6) 

While  the  Architecture  Framework  primarily  uses  this  view  to  describe  in  tabular  format  the 
information  exchanges  between  systems,  within  a  node,  and  to  systems  at  other  nodes,  it  is  more 
useful  fo  use  this  view  to  create  end-to-end  views  of  the  system  information  and  service 
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exchanges.  In  this  way,  the  expanded  SV-6  can  be  used  to  create  the  first  artifacts  of  the 
interoperability  of  the  FoS/SoS.  The  creation  of  these  artifacts  is  referred  to  as  the  static 
interoperability  assessment.  This  assessment  will  enable  the  architect  to  determine  if  the 
architecture  has  the  functionality  and  connectivity  needed  to  support  the  mission  capability. 

The  IBs  and  the  Operational  Event/Trace  Nodal  Description  (provided  previously  in  Figure  3-9) 
provide  the  means  to  identify  the  nodal  connections  and  associated  operational  activities.  These 
nodal  connections  with  their  associated  system  functions  are  summarized  in  the  Logical  Interface 
View  (provided  previously  as  Figure  3-12).  As  shown  in  the  graphic,  there  are  seven  connections 
to  be  made,  and  each  of  these  connections  is  presented  in  an  end-to-end  form  in  the  Systems 
Data  Exchange  Matrix  (SV-6)  presented  in  Table  3-7.  This  example  is  used  because  of  its 
simplicity,  but  in  practice,  this  matrix  can  be  very  large.  For  the  Navy’s  POM  04  Mission 
Capability  Package  (MCP)  for  Strike  Warfare,  the  SV-6  matrix  included  2,857  lines 
(connections).  When  these  lines  have  been  identified,  it  is  possible  to  use  standardized  databases 
to  determine  the  certification  of  each  of  the  interfaces.  In  the  Navy,  for  example,  the  Naval 
Command  for  Testing  System  Interoperability  (NCTSI)  maintains  this  kind  of  data. 

Table  3-7 


Systems  Data  Exchange  Nodal  Matrix  for  Precision  Engagement  Example 
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*Collection  Plan  is  updated  for  deconfliction. 
**Fire  Order  includes  Fire  Control  Solution. 
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Architecture  Assessments 

As  indicated  in  Figure  2-1  in  Chapter  2,  architecture  assessments  can  be  performed  on  two 
levels:  static  and  dynamic.  As  indicated  earlier  in  this  chapter,  the  static  assessment  is  performed 
using  the  Systems  Data  Exchange  Matrix  (SV-6)  and  provides  the  first  artifacts  of  FoS 
interoperability.  Dynamic  assessments  will  provide  insights  into  the  architecture  performance 
and  behavior.  At  the  time  of  the  writing  of  this  book,  no  mature  executable  models  have  been 
implemented  to  support  dynamic  assessments,  although  prototypes  have  been  investigated  in  the 
mission  areas  of  Time  Sensitive  Targeting  and  Theater  Air  Missile  Defense. 

For  the  Navy’s  POM  04  work  for  Time  Sensitive  Targeting,  a  logically  consistent  approach  has 
been  used  to  support  static  and  dynamic  assessments.  The  central  exhibits  for  this  work  were  the 
Operational  Event/Trace  Description  (OV-6c)  and  its  Nodal  representation.  The  same  diagrams 
were  used  by  system  engineers  to  provide  performance  predictions  in  the  context  of  standard 
scenarios^  and  by  architects  to  provide  static  interoperability  assessments  using  the  Systems  Data 
Exchange  Matrix  (SV-6)^^.  Performance  predictions  by  system  engineers  included  results  like 
the  Precision  Engagement  Targeting  capabilities  improvement  illustrated  in  Figure  1-3,  as  well 
as  predictions  of  lethality  and  survivability.  The  POM  04  Time  Sensitive  Targeting  work  was  the 
first  substantial  demonstration  of  the  arehitecture-based  systems  engineering  methodology 
presented  in  this  book.  It  is  hoped  that  future  work  will  lead  to  executable  models  that 
simultaneously  predict  performance  while  enabling  dynamic  assessment  of  interoperability. 

FoS/SoS  Concepts  versus  Classical  Systems  Engineering 

It  is  worthwhile  at  this  point  to  revisit  the  distinction  between  classical  systems  engineering  and 
architecture  based  on  FoS  engineering.  This  discussion  will  also  serve  to  demonstrate  the  power 
and  utility  of  the  abstractions  created  in  this  chapter. 

This  chapter  has  focused  on  an  architectural  abstraction  of  a  simple  example  of  NC  W  Precision 
Engagement  motivated  by  the  Guardrail  example  provided  in  Figure  1-2  in  Chapter  1.  Another 
way  to  describe  this  example  is  to  view  it  as  a  case  in  which  combat  systems  at  an  SoS  single 
platform  level  are  being  abstracted  to  an  FoS  force  level  implementation  using  network  centric 
concepts.  Figure  3-19  illustrates  this  point.  The  Aegis  Combat  system  illustrated  in  Figure  3- 19a 
is  based  on  an  activity  model  that  uses  the  Detect-Control-Engage  paradigm  for  Air  Defense 
missions.  When  this  combat  system  was  designed  (at  the  SoS  level)  nearly  30  years  ago,  the 
systems  engineer  made  classical  tradeoff  decisions  such  as  electing  a  use  a  new  phased  array 
radar  in  order  to  integrate  detection  and  fire  control  functions.  Decisions  were  also  made  to 
converge  the  multiple  surface-to-air  missiles  used  by  the  Navy  at  that  time  into  a  single  product 
line,  which  was  named  the  Standard  Missile.  The  systems  engineer  for  Aegis  did  have  boundary 
conditions,  but  clearly,  that  engineer  also  had  significant  latitude  in  the  design  of  the  SoS. 


^  The  POM  04  Time  Sensitive  Targeting  performance  predictions  were  performed  at  Naval  Air  Warfare  Center 
Weapons  Division,  China  Lake,  CA,  by  Dr.  Bob  Smith  et  al. 

The  POM  04  Time  Sensitive  Targeting  interoperability  assessments  were  performed  at  Space  and  Naval  Warfare 
Systems  Command  Systems  Center  Charleston,  SC,  by  Phil  Charles  et  al. 
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Figure  3- 19a.  Combat  System  Concept 
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Figure  3-19b.  Network  centric  Precision  Engagement 

Figure  3-19.  Comparison  of  SoS  and  FoS  Concepts  for  a  Combat  System 
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In  contrast  to  the  Aegis  example,  the  Precision  Engagement  example  ineludes  substantial  system 
boundary  conditions.  In  the  Precision  Engagement  case,  the  greatest  latitude  for  the  architect 
exists  in  how  the  given  systems  in  the  FoS  are  or  can  be  interoperated  in  order  to  aehieve  mission 
capabilities.  What  is  significant  about  the  architectural  abstractions  of  this  chapter  is  that  they 
ean  be  used  to  deseribe  both  the  SoS-level  eombat  system  (Figure  3-19a)  and  the  network  centric 
FoS-level  “combat  system”  (Figure  3- 19b).  It  is  also  significant  that  these  abstractions  can  be 
used  to  eross  warfare  mission  boundaries,  as  shown  by  the  faet  that  the  Aegis  example  addresses 
Air  Defense  while  the  network-centric  Precision  Engagement  example  addresses  targeting  of 
ground  targets.  This  applicability  of  a  single  “enterprise  model”  (i.e,  Deteet-Control-Engage)  to 
both  missions  was  accomplished  despite  the  fact  that  neither  the  Army  nor  the  Air  Force  uses  the 
Detect-Control-Engage  model. 

This  kind  of  abstraction  is  enabled  by  the  Architeeture  Framework  and  standardized  lists  of 
operational  activities  and  systems  fiinctions.  Figure  3-20  illustrates  the  architectural  foundations 
for  the  NCW  eoneept  introdueed  in  Figure  1-4  of  Chapter  1.  The  key  exhibit  is  the  Operational 
Event/Trace  Nodal  Description  (Figure  3-20a).  It  is  supplemented  by  the  concept  described  in 
Figure  3 -20b,  which  illustrates  the  network  centrie  vision  that  John  Gartska  popularized  through 
a  widely  distributed  graphic  entitled  Networking  the  Force  (Figure  1-4).  In  Mr.  Gartska’s 
graphie,  the  Sensor  Fusion  level  eorresponds  to  the  Deteet  and  Control  nodes  in  the  Preeision 
Engagement  example.  The  Force  Control  Level  corresponds  to  the  Operational  Command  node, 
and  the  Foree  Coordination  Level  eorresponds  to  the  Theater  Command  node. 
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Figure  3 -20a.  Operational  Event/Trace  Nodal  Description 
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Figure  3-20b.  Networking  the  Force 

Figure  3-20.  Architectural  Foundations  for  NCW  Concepts 


Summary 

The  goal  of  this  chapter  was  to  show  how  three  of  the  basic  groups  of  architecture  products 
introduced  in  Chapter  2  provide  a  framework  to  describe  a  mission  warfare  area  and  demonstrate 
the  logical  validity  of  the  mission  and  system  architecture.  Table  3-8  summarizes  the  architecture 
products  in  the  order  they  were  developed  to  support  the  abstract  NCW  architecture.  The 
summary  exhibit,  Figure  3-18  (the  combined  System  Interface  Description  (SV-1)  and  System 
Communications  Description  (SV-2)  presented  earlier  in  this  chapter),  shows  abstractly  an 
example  of  the  linkage  between  the  operational,  system,  and  technical  views  of  the  architecture 
for  NCW.  The  Operational  Event/Trace  Nodal  Description  (the  version  of  the  OV-6c  presented 
in  Figure  3-9)  is  the  foundational  exhibit  that  allows  abstraction  of  the  architecture. 


Table  3-8 

Summary  of  Architecture  Products 


Nomenclature 

Name 

Figure 

Number 

Operational  Concept 

OV-1 

High-Level  Operational  Concept  Graphic 

Figure  3-2 

OV-5 

Operational  Activity  Model 

Tables  3-1,  3-2 

OV-2 

Operational  Node  Connectivity  Description 

Figure  3-5 

OV-4 

Organizational  Relationships 

Figure  3-7 

OV-6c 

Operational  Event/Trace  Description 

Figure  3-8 

OV-6c  Nodal 

Operational  Event/Trace  Nodal  Description 

Figure  3-9 

OV-3 

Operational  Information  Exchange  Matrix 

Table  3-4 
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System  Functional 

SV-4a 

High-Level  Systems  Funetions  List 

Table  3-5 

SV-5 

Operational  Aetivity  to  System  Function  Traceability 
Matrix 

Figure  3-10 
Table  3-6 

SV-4b 

Systems  Functional  View 

Figure  3-11 

SV-4c 

Logical  Interface  View 

Figure  3-12 

SV-3a 

Systems  to  Functions  Matrix 

Figure  3-13 

SV-3b 

Operational  Activity  to  System  Traceability  Matrix 

Figure  3-14 

SV-3c 

Systems^  Matrix 

Figure  3-15 

System  Interface 

SV-1 

Systems  Interface  Description 

Figure  3- 16a 

SV-2 

System  Communications  Description 

Figure  3- 16b 

SV-3c  Nodal 

Nodal  Version  of  the  Systems^  Matrix 

Figure  3-17 

OV-2  Instantiated 

Instantiated  Version  of  Operational  Node  Connectivity 
Description 

Figure  3-18 

TV-1 

Technical  Standards  Profde 

Page  3-25, 26 

SV-6 

Systems  Data  Exchange  Nodal  Matrix 

Table  3-7 
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CHAPTER  4 

PRECISION  ENGAGEMENT 


Purpose 

The  previous  chapter  provided  background  on  NCW  and  presented  an  abstraction  of  the  role  of 
network  centricity  as  a  warfare  enabler.  This  case  study  focuses  on  a  specific  warfare  mission 
capability,  Precision  Engagement,  and  provides  a  discussion  of  the  instantiation  of  the  NCW 
abstraction  using  the  example  carried  through  Chapters  1  and  3.  This  Precision  Engagement  case 
study  provides  a  concrete  example  of  how  the  Architecture  Framework  products  can  be  used  to 
describe  the  ability  of  an  FoS  to  deliver  mission  capabilities.  It  illustrates  the  methods  used  in 
building  a  warfare  mission  architecture  with  traceability  of  FoS  functionality  and  connectivity  to 
capability  objectives.  This  chapter  provides  an  architectural  assessment  of  how  mission 
capabilities  are  achieved  through  the  interoperation  of  systems.  It  offers  the  first  artifact  that 
validates  the  interoperability  of  the  FoS  architecture  for  the  Precision  Engagement  example  of 
NCW. 

Precision  Engagement  Operational  Concept 

It  is  critical  to  remember  that  NCW  is  a  warfare  enabler  and  is  focused  on  leveraging  network  centricity 
as  a  means  for  improving  specific  warfare  missions.  One  such  mission  is  Precision  Engagement.  The 
first  step  in  developing  architecture  products  for  the  Precision  Engagement  mission  is  to  develop 
operational  concept  views.  The  five  architecture  products  that  support  the  Precision  Engagement 
operational  concept  include  the  following  views: 

•  High-Level  Operational  Concept  (OV- 1 ) 

•  Command  Relationships  Chart  (OV-4) 

•  Activity  Model  (OV-5) 

•  Operational  Node  Connectivity  Description  (OV-2) 

•  Operational  Event/Trace  Description  (OV-6c) 

Each  is  described  at  a  high  level  in  the  following  paragraphs.  The  NCW  concepts  of  Chapter  3  provide 
the  basis  for  these  products. 

High  Level  Operational  Concept  Graphic  (OV-1) 

The  warfare  mission  capability  discussed  in  this  case  study  is  Precision  Engagement  and,  more 
specifically,  coordinated  operations  from  dispersed  assets  in  support  of  Precision  Engagements. 
Figure  4-1  repeats  the  illustration  of  the  Precision  Engagement  Operational  Concept  introduced 
in  Chapters  1  and  3.  This  graphic  is  based  on  the  network  centric  engagement  concept.  The 
NCW  Precision  Engagement  example  introduced  in  Chapter  3  showed  how  the  Theater 
Commander  could  use  network  centricity  to  engage  a  C2  target.  Figure  4-1  illustrates  how  three 
command  levels  (force  coordination,  force  control,  and  sensor  fiision,  as  introduced  in  Figure  1-4 
of  Chapter  1)  are  networked  and  how  they  use  Tasking,  Collection,  Processing,  Exploitation,  and 
Dissemination  (TCPED)  and  Precision  Navigation  and  Timing  (PNT)  to  engage  a  precision 
target.  PNT  must  be  shared  across  all  nodes  of  the  architecture.  The  TCPED  of  data  from 
National  Technical  Means  (NTM)  in  this  concept  is  shared  with  the  theater  commander  and 
fused  with  sensor  data  by  the  tactical  commander. 
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Figure  4-1.  Precision  Engagement  High-Level  Notional  Operational  Concept  Graphic  (OV-1) 

In  this  example,  the  Battlespace  includes  various  threat  targets  on  land  that  are  attacked  using 
assets  from  land,  space,  or  air.  The  Battlespace  is  defined  in  the  Joint  doctrine  to  be  the 
environment,  factors,  and  conditions  that  must  be  understood  to  apply  combat  power,  project  the 
force,  or  complete  the  mission  successfiilly.^'  It  is  the  environment  where  the  military  force  will 
affect  the  threat  (or  vice  versa),  and  thus  will  have  relationships  with  both  elements.  The  physical 
environment  of  the  Battlespace  provides  a  good  example  of  the  various  dimensions  that  impact 
the  key  elements  of  the  operational  concept  and  their  relationships.  Such  dimensions  could 
include  weather,  radio  frequency  (RF)  or  infrared  (IR)  clutter,  or  even  electromagnetic 
interference  (EMI)  that  is  not  threat  related.  Battlespace  effects  are  defined  in  the  Joint  doctrine 
lexicon  as  the  degree  of  control  over  the  dimensions  of  the  Battlespace  that  enhance  freedom  of 
action  for  friendly  forces  or  deny  the  enemy  freedom  of  action.  These  dimensions  exist  within 
the  operational  areas  and  the  areas  of  interest  and  include  the  air,  land,  sea,  and  space;  the 
included  enemy  and  friendly  forces;  facilities;  weather;  terrain;  the  electromagnetic  spectrum; 
and  the  information  environment.^^ 

The  effect  sought  in  the  Battlespace  is  to  achieve  lethality  against  the  targets  while  maintaining  a 
minimal  targeting  error,  thus  reducing  the  need  for  repeated  weapons  expenditures  and  the  risk 
of  collateral  damage.  This  could  be  a  complicated  Joint  theater,  requiring  significant 
coordination  and  deconfliction.  The  precision  attack  in  this  concept  represents  a  use  case  that 
could  be  instantiated  through  the  use  of  many  different  types  of  military  force.  Thus  the  simple 
graphic  of  the  key  elements  of  the  operational  concept  shown  in  Chapter  3  (Figure  3-1)  will  give 
rise  to  a  more  complicated  graphic  that  remains  organized  around  the  simpler  concept  of  Figure 
3-1. 
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Command  Relationships  (OV-4) 

The  Precision  Engagement  Operational  Concept  illustrated  in  Figure  4-1  achieves  mission 
effectiveness  through  the  sharing  of  data  through  a  geographically  dispersed  FoS.  Figure  4-2 
illustrates  the  command  relationships  at  the  highest  levels.  This  graphic  shows  command 
relationships  down  to  the  operational  level,  which  is  where  the  precision  engagement  concept 
begins  in  Figure  3-1. 


Acronyms: 

JFC:  Joint  Force  Commander 

JFSOCC:  Joint  Force  Special  Operations  Component  Commander 
JFACC:  Joint  Force  Air  Component  Commander 
JFLCC;  Joint  Force  Level  Component  Commander 
JFMCC:  Joint  Force  Maritime  Component  Commander 

*Previously  known  as  one  of  several  Commanders  in  Chief  (CINCs) 

Figure  4-2.  Precision  Engagement  Command  Relationships 

Activity  Model  (OV-5) 

The  Precision  Engagement  operational  concept  used  in  this  case  study  is  based  on  the  Joint 
Targeting  Doctrine  illustrated  in  Figure  4-3.  This  doctrine  is  referred  to  as  illustrative  because 
the  architecture  development  in  this  book  predates  the  current  Precision  Engagement  operational 
concept  developed  by  the  Joint  Staff.  Because  this  book  is  intended  to  illustrate  the  methodology 
and  not  current  doctrine,  the  illustrative  doctrine  will  be  sufficient  for  the  purposes  of  this  book. 

While  the  Activity  Model  implied  by  Figure  4-3  may  appear  to  be  substantially  different  than  the 
Detect-Control-Engage  paradigm  used  in  Chapter  3,  it  will  become  apparent  that  the  two  views 
are  intimately  related.  The  primary  difference  is  that  the  doctrine-based  activity  hierarchy 
augments  the  Joint  Targeting  model  with  TPCED  activities. 
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Figure  4-3.  Illustrative  Precision  Engagement  Doctrine* 

*The  Joint  Doctrine  has  been  revised;  this  example  is  historical  and  has  been  used  for  illustrative  purposes. 

Figure  4-4  provides  the  historical  doctrine-based  hierarchy  decomposed  to  a  second-level 
hierarchy  that  specifically  addresses  the  Precision  Engagement  warfare  capability.  The 
Command  and  Control  activity  model  includes  the  Common  Ground  Picture  (CGP)  and  the 
Single  Integrated  Air  Picture  (SIAP).  Theater  sensors  can  be  monitored  directly  or  through  the 
CGP  and  SIAP.  The  hierarchy  is  based  on  Commander’s  Guidance,  Target  Development,  the 
Weaponeering  Assessment,  and  the  other  doctrine-based  activities  of  Figure  4-3.  Target 
Development  includes  activities  such  as  determining  target  location  and  identification.  It  also 
includes  assessment  of  the  candidate  target(s)  against  the  Air  Tasking  Order  (ATO).  The 
Weaponeering  Assessment  will  include  a  determination  of  whether  or  not  the  required  effects 
and  time  on  target  (provided  by  the  Commander’s  objectives  and  guidance)  can  be  achieved. 
Additionally,  this  assessment  will  include  determination  (using  the  CGP  or  theater  sensors)  of 
the  accuracy  of  the  target  location  and  guidance  on  collateral  damage.  The  resulting  output  is  a 
list  of  weapon  target  pairings  (WTPs)  from  which  final  selection  will  be  made.  During  Target 
Development,  changes  in  the  target  status  must  also  be  assessed.  These  changes  could  be  the 
result  of  target  activity  reported  through  the  sensors  or  a  change  in  the  Commander’s  objectives. 
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Precision 

Engagement 

1.0 


1.1 

Commander’s 

Guidance 


—  1.1.1  Task  Order 

-ATO 

-ROE 

—  1.1.2  Common  Pictures 

-  Common 
Operational 
Picture 

-  Common  Ground 
Picture 

-  Single  Integrated  Air 
Picture 

— 1.1.3  Availability  Sensors 

—  1.1.4  Weapon  Availability 


1.2 

Target 

Development 


—  1.2.1  Location 

—  1.2.2  Identification 

—  1 .2.3  Comparison  with 

ATO 


1.4 

Force 

Application 


—  1.4.1  Weapon  Target  Plan 

-  Weapon 
Target 
Pairing 
Selection 

-  Deconfliction 

-  Launch  Site 

I—  1.4.2  Dynamic  Operations 


1.6 

Combat 

Assessment 


—  1.6.1  Requirement  for  Assets 

—  1 .6.2  Damage/Effects 

—  1.6.3  Requirement  to 

Continue  Operations 

—  1.6.4  Dynamic  Replanning 
_  1 .6.5  Request  for  New 

Engagement 


1.3 

Weaponeering 

Assessment 


1.5 

Force 

Execution 


1.3.1  Guidance 

-  Effects  Required 

-  Time  on  Target 

-  Accuracy 

-  Collateral  Damage 
Guidance 

1.3.2  Weapon  Targeting 
Paring  Options 

1.3.3  Target  Status 


—  1.5.1  Issue  of  Orders 

-  Operations  Orders 

-  Weapons  Orders 
*—  1 .5.2  Execution  of  Orders 


Figure  4-4.  NCW  Operational  Activity  Model  (OV-5)  for  Precision  Engagement 


Force  Application  includes  Damage  Assessments  and  planning  of  Dynamic  Operations.  During 
Force  Application  planning,  a  final  WTP  selection  will  be  made,  and  the  launch  time  for  the 
weapon  will  be  established.  Deconfliction  is  also  part  of  Force  Application  planning.  Force 
Execution  includes  issuing  orders  for  both  launch  of  the  weapon  and  other  operations  that  may 
be  related  to  the  engagement  or  affected  by  it.  Requests  for  assets  are  made  through  the  theater 
commander  (the  JFACC),  who  in  turn  provides  the  assets.  The  Force  Application  activity 
triggers  execution  of  Deliberate  Operations  by  the  military  force.  Dynamic  Operations  activities 
differ  from  Deliberate  Operations  activities  in  that  Dynamic  Operations  include  adjustments  that 
are  made  concurrently  with  the  conduct  of  the  mission  execution,  while  Deliberate  Operations 
are  based  only  upon  planning  that  occurs  before  the  execution  of  the  mission.  Finally,  to  conduct 
the  Combat  Assessment  activity,  it  first  must  be  determined  if  the  assets  involved  in  the 
engagement  should  continue  their  mission.  Requests  to  continue  and  for  the  requisite  assets  are 
made  through  the  planning  activities. 


The  historical  hierarchy  shown  in  Figure  4-4  was  presented  to  show  what  a  reasonable 
operational  activity  model  based  on  military  doctrine  might  look  like.  Figure  4-5  shows  how  this 
compares  with  the  Activity  Model  developed  in  Chapter  3.  The  doctrine-based  hierarchy  model 
shown  in  Figure  4-4  has  a  clear  correlation  with  the  Activity  Model  shown  in  Chapter  3, 
although  several  of  the  top-level  doctrinal  activities  are  performed  across  more  than  one  of  the 
Detect-Control-Engage  activities. 
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Doctrine-Based  Activities 

Detect-Control-Engage  Farad 

igm  Activil 

lies 

Theater 

Command 

Operational 

Command 

Detect 

Control 

Engage 

1.1  Commander’s  Guidance 

V 

1.2  Target  Development 

1.3  Weaponeering  Assessment 

1.4  Force  Application 

V 

1.5  Force  Execution 

1.6  Combat  Assessment 

Figure  4-5. 
Paradigm 


Relationship  between  Doctrine-Based  Hierarchy  and  Detect-Control-Engage 


Operational  Node  Connectivity  Description  (OV-2) 

Using  the  correlations  developed  in  Figure  4-5,  the  Operational  Node  Connectivity  Description 
(OV-2)  for  the  Activity  Model  described  in  Chapter  3  can  be  used  to  support  the  doctrine-based 
activities.  It  is  necessary,  however,  to  amend  the  previously  presented  Operational  Node 
Cormectivity  Description  to  include  the  use  of  NTM.  No  changes  will  be  required  to  the  list  of 
IBs,  because  NTM  simply  becomes  another  source  for  sensor  reports.  The  revised  Operational 
Node  Cormectivity  Description  is  shown  in  Figure  4-6.  The  Theater  Command  in  this  example 
would  be  the  JFACC,  and  the  Operational  Commander  would  be  the  Army  Corps  Commander. 


Example 

Comparing  the  relationship  between  the  doctrine-based  and  Detect-Control-Engage  paradigm- 
based  activities  (provided  in  Figure  4-5)  and  the  Nodal  Description  (shown  in  Figure  4-6)  reveals 
an  important  point:  high-level  doctrine-based  activities  are  not  necessarily  operational  nodes.  In 
this  Precision  Engagement  example,  only  one  such  activity,  the  Commander’s  Guidance  (1.1),  is 
a  node;  specifically,  it  is  the  Theater  Command  node.  The  remaining  doctrine-based  activities  are 
either  aggregated  into  a  single  node  (e.g.,  Weaponeering  Assessment  (1.3),  Force  Application 
(1.4),  and  Combat  Assessment  (1.6)  are  aggregated  into  the  Operational  Command  node),  or 
they  are  allocated  across  multiple  nodes  (e.g..  Target  Development  (1.2)  is  allocated  across  the 
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Detect  and  Control  nodes).  It  must  be  remembered  that  operational  activities  are  things  to  be 
done  (actions  to  be  taken),  whereas  operational  nodes  are  meaningful  groupings  of  operational 
activities  that  will  be  supported  by  communications  and  other  related  physical  instantiations. 

Operational  Event/Trace  Description  (OV-6c) 

Figure  4-7  provides  the  revised  version  of  the  Operational  Event/Trace  Nodal  Description  (OV- 
6c  Nodal)  based  on  the  one  previously  presented  in  Chapter  3  (Figure  3-9)  and  the  more  detailed 
descriptions  of  the  operational  concept  (Figure  4-1)  and  the  nodal  description  (Figure  4-6) 
presented  in  this  chapter.  One  new  node  has  been  added  for  NTM,  and  this  node  includes  the 
TCPED  activities  associated  with  gathering  Intelligence,  Surveillance,  and  Reconnaissance  (ISR) 
data.  This  node  provides  additional  sensor  reports  to  the  Control  node.  For  example,  NTM  may 
provide  imaging  data  to  complement  the  passive  data  of  the  Detect  node  to  give  additional 
capahilities  for  target  identification  and  geolocation.  With  the  exception  of  the  addition  of  the 
new  node,  the  model  is  identical  to  the  one  presented  in  Chapter  3. 


Sensor 

Reports 


Weapon 

Launch 

Report 


Figure  4-7.  Operational  Event/Trace  Nodal  Description  (OV-6c  Nodal) 


To  further  clarify  the  information  in  the  Operational  Event/Trace  Nodal  Description,  basic 
elements  from  this  diagram  can  be  extracted  to  show  the  producing  and  consuming  nodes  along 
with  their  required  information  elements.  Table  4-1  shows  the  Operational  Event/Trace  Nodal 
Description  interfaces  (identified  by  their  assigned  numbers  in  Figure  4-7)  along  with  their 
sources  nodes,  lEs,  and  destination  nodes.  Amplifying  information  is  provided  in  Table  4-2, 
which  adds  the  associated  activities  to  the  interfaces,  source  and  destination  nodes,  and  lEs. 
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Table  4-1 


Interfaces,  lEs,  Source  Nodes,  and  Destination  Nodes 


OV-6c 

Interface 

Identifier 

IE 

Source  Node 

Destination  Node 

1 

Sensor  Reports 

NTM 

Theater  Command 

4 

Sensor  Reports 

NTM 

Control 

2 

Colleetion  Requirements 

Theater  Command 

NTM 

3 

Task  Order  &  Guidance 

Theater  Command 

Operational  Command 

7 

Weapon  Target  Plan 

Operational  Command 

Control 

5 

Mission  Plan 

Operational  Command 

Control 

5 

Collection  Plan 

Operational  Command 

Control 

6 

Permission  to  Fire 

Operational  Command 

Control 

8 

Sensor  Reports 

Detect  (Guardrail) 

Control 

8 

Sensor  Reports 

Detect  (UAV) 

Control 

5 

Collection  Plan 

Control 

Detect  (Guardrail) 

5 

Collection  Plan 

Control 

Detect  (UAV) 

9 

Target  Nomination 

Control 

Operational  Command 

10 

Fire  Order 

Control 

Engage 

11 

Weapons  Launch  Report 

Engage 

Operational  Command 

Interfaces,  lEs, 


Table  4-2 

Source  Nodes,  and  Destination  Nodes  (With  Activities) 


OV-6c 
Inter¬ 
face  ID 


Source 


Destination 


Sensor  Reports 

Sensor  Reports 
Collection 
Requirements 
Task  Order  & 

Guidance _ 

Wpn.  Tgt.  Plan 
Mission  Plan 
Collection  Plan 
Perm,  to  Fire 
Sensor  Reports 
Sensor  Reports 
Collection  Plan 
Collection  Plan 
Target  Nom. 

Fire  Order _ 

Wpn.  Launch  Rpt. 


Source  Node 


NTM _ 

Theater  Com. 

Theater  Com. 

Op.  Command 
Op.  Command 
Op.  Command 
Op.  Command 
Detect  (Guardrail) 
Detect  (UAV) 

Control _ 

Control _ 

Control _ 

Control _ 

Engage _ 


Activity 


TCPED 

TCPED 
Issue  Task 
Order/Guidance 
Issue  Task 
Order/Guidance 
Update  Miss.  Plan 
Deconflict  Airspace 
Update  Miss.  Plan 
Grant  Perm,  to  Fire 
Detect  Tgt. /Environ. 
Detect  Tgt./Environ. 

Control _ 

Control _ 

Nominate  Target 
Issue  Fire  Order 
Weapon  Fly-Out 


Best.  Node 


Theater  Com. 

Control _ 

NTM 

Op.  Com. 

Control _ 

Control _ 

Control _ 

Control _ 

Control _ 

Control _ 

Detect  (GR) 
Detect  (UAV) 
Op.  Com. 

Engage _ 

Op  Com. _ 


Activity 


Issue  Task 
Order/Guidance 

ID  Target _ 

TPCED 

Update  Miss.  Plan 

Issue  Fire  Order 

Control _ 

Mission  Execution. 
Issue  Fire  Order 
ID/Geolocate  Targ. 
ID/Geolocate  Targ. 
Detect  Tgt./Environ. 
Detect  Tgt./Environ. 
Grant  Perm,  to  Fire 
Weapon  Fly-Out 
Update  Miss.  Plan 
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System  Functional  Mapping 

The  five  principal  types  of  systems  can  be  used  to  organize  lists  of  actual  physical  systems  that 
enable  the  systems  functions.  This  type  of  organization  is  shown  in  Table  4-3.  The  physical 
systems  lists  can  come  from  any  number  of  sources,  including  POM  acquisition  plans, 
Battleforce  Orders  of  Battle,  Operational  Use  Cases,  or  proposals  by  system  developers  or  the 
science  and  technology  community.  The  list  used  to  illustrate  the  assemblage  of  the  FoS  in  this 
case  study  has  been  taken  from  the  Precision  Engagement  high-level  concept  graphic  (OV-1) 
presented  previously  in  Figure  4-1. 


Table  4-3 


Case  Systems  List  for  Precision  Enga; 

cement  Examp 

le 

Networks 

Sensors 

Processors 

Weapons 

Platforms 

•  CDL 

•  GSM  Network/Links 

•  SATCOM/TRIXS 

•  Senior  Glass 

•  Guardrail 
Common 
Sensor 
(GRCS) 

•  ASAS 

•  TBMCS 

•  AFATDS 

•  ATACMS 

•  Future  High- 
Altitude  UAV 

•  Guardrail 

•  GSM 

Systems  Matrices  (SV-3) 

Using  the  systems  listed  in  Table  4-1,  it  is  then  possible  to  develop  the  System-to-Systems 
Functions  Matrix  (SV-3a)  shown  in  Figure  4-8.  Links  will  be  considered  as  a  special  type  of 
network,  namely  a  point-to-point  network  (vice  a  many-to-one  or  many-to-many  connection). 
Figure  4-9,  the  Operational  Activity  to  System  Traceability  Matrix  (SV-3b),  is  the  companion 
matrix  that  relates  systems  to  operational  activities. 


Enabling 

System 

System  Function  | 

Sense 

Command 

Act 

Interoperate 

Networks 

SATCOM 

Multiple  Subscriber 
Equipment  (MSE) 

TRIX,  GSM  Network 
Links,  MSE 

Sensors 

Senior  Glass, 
GRCS 

Processors 

ASAS,  TBMCS 

AFATDS 

DCGS-A 

Weapons 

ATACMS 

Platforms 

Multiple  Launch  Rocket 
System  (MLRS) 

Figure  4-8.  Systems-to-Systems  Functions  Matrix  (SV-3a)  for  Precision  Engagement  Example 


Enabling 

System 

Operational  Activity  | 

Detect 

Control 

Engage 

Sensor 

Senior  Glass,  GRCS 

Processor 

ASAS 

Weapon 

ATACMS 

Figure  4-9.  Operational  Activity  to  System  Traceability  Matrix  (SV-3b)  for  Precision 
Engagement  Example 
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The  operational  concept  described  in  the  previous  section  of  this  chapter  expresses  the  concept 
for  system  interoperation  as  well  as  command  and  control  from  the  theater  level.  The  Systems^ 
Matrix  (SV-3c  Nodal),  shown  in  Figure  4-10,  provides  a  view  of  the  operational  concept  (shown 
previously  in  Figure  4-1)  through  nodal  relations  and  more  specifically  reveals  the  nodal 
connectivity  illustrated  earlier  in  this  chapter  in  Figure  4-6. 


GRCS 

Senior  Glass 

TBMCS 

ASAS 

ATACM 

Guardrail 

- 

- 

CDL-SATCOM 

- 

Senior  Glass 

- 

CDL-SATCOM 

- 

TBMCS 

SATCOM 

- 

ASAS 

Fiber  Optic 

ATACM 

Note:  Platform  control  Is  provided  by  UHFA/HF  Comms. 


2 

"igure  4-10.  Nodal  System  Matrix  (SV-3c  Nodal)  for  Precision  Engagement  Example 

System  Interface  Mapping 

System  Interface  Mapping  for  the  Precision  Engagement  example  can  be  supported  through  the 
use  of  three  Architecture  Framework  products: 

•  Operational  Node  Connectivity  Description  (OV-2)  instantiated  with  actual  systems 

•  Technical  Architecture  Profile  (TV-1) 

•  Systems  Information  Exchange  Matrix  (SV-6c) 

Each  of  these  products  is  described  in  the  following  paragraphs. 

Instantiated  Operational  Node  Connectivity  Description  (OV-2) 

Figure  4-11  provides  an  instantiated  Operational  Node  Connectivity  Description  (OV-2)  for  the 
Precision  Engagement  example.  As  shown,  FoS  level  detection  in  the  Battlespace  is  carried  out 
by  four  sensors  complemented  by  TCPED.  The  fundamental  activities  of  Detect,  Control,  and 
Engage  for  the  FoS  and  for  Command  and  Control  are  organized  into  the  same  nodes  used 
previously  in  Chapter  3.  Similarly,  FoS  level  execution  is  organized  into  a  separate  node.  Figure 
4-11  also  shows  how  the  need  lines  are  instantiated. 

Technical  Architecture  Profile  (TV-1) 

The  technical  component  of  the  architecture  provides  the  set  of  rules  and  standards  that  govern 
system  implementation  and  operation.  In  the  case  of  FoS  systems  engineering,  the  standards  and 
protocols  associated  with  the  transport  layer  of  interfacing  and  communications  between  systems 
will  be  especially  important.  Table  4-4  provides  a  Technical  Architecture  Profile  that  applies  to 
the  FoS  systems  for  the  Precision  Engagement  example.  This  profile  can  be  considered  a 
comprehensive  list  from  which  applicable  standards  and  protocols  can  be  selected  based  on  the 
specific  systems  used  to  support  the  mission.  Table  4-1,  shown  previously  in  this  chapter, 
provided  the  lists  of  systems. 
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FoS  Activity  FoS  Node 


Operational 

Command 


Detect 


Control 


Engage 


Legend: 


Networks 


□  =  Sensors 


I  I  =  Processors 


□  =  Weapon 


Figure  4-11.  Instantiated  Operational  Node  Connectivity  Description  (OV-2)  for  Precision 
Engagement  Example 


Table  4-4 


Technical  Architecture  Profile  for  Precision  Engagement  Example 


Interface 

Category 

Protocol 

Common 

Name 

Reference 

Standard 

Description 

Communications  Equipment 

CDL 

NATO 

STANAG 

7085 

Interoperable  Data  Links  for  Multi-INT  Systems 

TRIXS 

UHF  (LOS) 

TIBS 

UHF 

(SATCOM) 

MIL-STD- 

188-181B 

Standard  for  Single  Access  5 -Khz  and  25 -Khz 
UHF  Satellite  Communications  Channels,  20 
March  1999 

MIL-STD- 

188-164 

Interoperability  and  Performance  Standards  for 
C-Band,  X-Band,  and  Change  1,  9  September 

1998 

TRAP 

UHF 

(SATCOM) 

MIL-STD- 

188-181B 

Standard  for  Single  Access  5 -Khz  and  25 -Khz 
UHF  Satellite  Communications  Channels,  20 
March  1999 

MIL-STD- 

188-164 

Interoperability  and  Performance  Standards  for 
C-Band,  X-Band,  and  Change  1,  9  September 

1998 

Using  Architectures  for  Research,  Development,  and  Acquisition 


62 


IBS 

UHF 

(SATCOM) 

MIL-STD- 

188-181B 

Standard  for  Single  Access  5 -Khz  and  25 -Khz 
UHF  Satellite  Communications  Channels,  20 
March  1999 

MIL-STD- 

188-164 

Interoperability  and  Performance  Standards  for 
C-Band,  X-Band,  and  Change  1,  9  September 

1998 

MSE 

SINGARS 

VHF-FM 

(LOS) 

TADIL-J 

UHF  (LOS) 

MIL-STD- 

6016 

TADIL-B 

Two-Wire 

HDSL 

Processing  j 

Equipment 

CTT/JTT 

TCP/IP 

IETF  1122 

Network  Interface 

IETF  1123 

Application  Protocol 

SMTP 

IETF 

Simple  Mail  Transfer  Protocol 

Standard 

10/ElFC 

821/RFC 

1869/RFC 

1870 


AFATDS 

TCP/IP 

IETF  1122 

Network  Interface 

IETF  1123 

Application  Protocol 

SMTP 

IETF 

Simple  Mail  Transfer  Protocol 

Standard 

10/RFC 

821/RFC 

1869/RFC 

1870 


ASAS 

TCP/IP 

IETF  1122 

Network  Interface 

IETF  1123 

Application  Protocol 

1  Information  Elements  \ 

Character- 

Oriented 

Messages 

USMTF 

Imagery 

NATO 

STANAG 

7023 

Primary  Imagery  Format 

Imagery 

MIL-STD- 

2500B 

National  Imagery  Transmission  Format  V2.1 

Imagery 

NATO 

STANAG 

4545 

Secondary  Imagery  Format 

Imagery 

Library 

NATO 

STANAG 

4559 

Standard  Imagery  Library  Interface 

JTIDS 

Message 

MIL-STD 

6016 

J  Series  Message  Formats 

Using  Architectures  for  Research,  Development,  and  Acquisition 


63 


From  the  comprehensive  list  of  standards  and  protocols  provided  in  Table  4-4,  a  list  of  standards 
and  protocols  that  apply  to  the  system  connections  in  the  Precision  Engagement  example  can  be 
identified.  Table  4-5  provides  the  Operational  Event/Trace  Nodal  Description  interfaces 
(identified  by  their  assigned  numbers  in  Figure  4-7)  along  with  their  lEs,  source  and  destination 
systems  and  functions,  and  the  source  and  destination  system  protocols. 

Table  4-5 


Interfaces,  lEs,  and  Source  and  Destination  Systems,  System  Functions,  and  Protocols 


OV-6c 
Inter¬ 
face  ID 

IE 

Source 

System 

Source 

System 

Function 

Source 

System 

Protocol 

Destiuatiou 

System 

Destiuatiou 

System 

Fuuctiou 

Dest. 

System 

Protocol 

1 

Sensor 

Reports 

NTM 

TCPED 

NTF, 

USMTF 

JDISS 

Decision 

Planning 

NTF, 

USMTF 

4 

Sensor 

Reports 

NTM 

TCPED 

NTF, 

USMTF 

TOC  CTT, 
ASAS, 

TROJAN 

Target  ID 

NTF, 

USMTF 

2 

Collection 

Reqs. 

JDISS 

Task 

Sensors 

USMTF 

NTM 

Multi- Sensor 
Sense 

USMTF 

3 

Task 

Order/ 

Guidance 

JTF  TBMCS, 
GCCS 

Update 

Mission 

Plan 

USMTF 

JFACC 

TBMCS, 

GCCS 

Update  Mission 
Plan 

USMTF 

7 

Wpn.  Tgt. 
Plan 

JFACC 

GCCS 

Weapon 

Tgt  Assoc. 

USMTF 

TOC 

AFATDS 

Issue  Fire  Order 

USMTF 

5 

Mission 

Plan 

JFACC 

TBMCS 

Air  Pic.  Int., 
Dyn. 

Deconflict. 

USMTF 

TOC  GCCS 

Mission 

Execution 

USMTF 

5 

Collection 

Plan 

JFACC 

GCCS 

Collection 

Planning 

USMTF 

TOC  GCCS 

Mission 

Execution 

USMTF 

5 

Collection 

Plan 

JFACC  UHF 

SATCOM 

Radio 

Collection 

Execution 

USMTF 

UAV  UHF 
SATCOM 

Radio 

Single  Sensor 
Sense 

Voice 

6 

Permission 
to  Fire 

JFLCC 

GCCS 

Decision, 

Target 

Prioritiz. 

USMTF 

TOC 

AFATDS 

Issue  Fire  Order 

USMTF 

8 

Sensor 

Reports 

Guardrail 

CTT 

Single 

Sensor 

Sense 

USMTF 

GSM  ASAS 

Multi- Sensor 
Sense,  Feat. 
Extraction 

USMTF 

8 

Sensor 

Reports 

UAV 

SYERS/ 

ASARS/IRIS 

Single 

Sensor 

Sense 

Binary 

GSM  ASAS, 
TROJAN 

Multi- Sensor 
Sense,  Feat. 
Extraction 

Binary 

5 

Collection 

Plan 

GSM  UHF 
Radio 

Collection 

Execution 

Voice 

Guardrail  UHF 
Radio 

Single  Sensor 
Sense 

Voice 

5 

Collection 

Plan 

CARS/ 

DCGS 

Collection 

Execution 

Binary 

UAV  SYERS/ 
ASARS/IRIS 

Single  Sensor 
Sense 

Binary 

9 

Target 

Nom. 

TOC  GCCS 

Decision, 

Target 

Prioritiz. 

USMTF 

JFACC  GCCS 

Decision, 

Target  Prioritiz. 

USMTF 

10 

Fire  Order 

TOC 

AFATDS 

Issue  Fire 
Order 

USMTF 

MLRS-FDC, 

AFATDS, 

ATACMS 

Weapon 
Initialization 
and  Launch 

USMTF 

11 

Wpn. 

Launch 

Rpt. 

MLRS  FDC 
AFATDS 

Weapon 
Initialization 
&  Launch 

USMTF 

JEACC 

AGCCS 

Collection 

Planning 

USMTF 
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Systems  Information  Exchange  Matrix  (SV-6) 

Throughout  this  chapter,  the  discussion  has  focused  on  the  instantiation  of  the  NCW  abstraction 
presented  in  Chapter  3  using  an  actual  NCW  mission,  Precision  Engagement.  The  development 
of  the  Architecture  Framework’s  Systems  Information  Exchange  Matrix  (SV-6)  is  the 
culmination  of  the  logical,  progressive  building  of  Architecture  Framework  products  to  describe 
the  static  interoperability  of  an  FoS  to  deliver  mission  capabilities.  Table  4-6,  which  is  shown  on 
the  following  page,  presents  an  expanded  view  of  the  System  Information  Exchange  Matrix.  It 
retains  the  attributes  of  the  existing  Framework  product,  which  is  defined  as  the  information 
exchanges  within  a  node  and  from  those  systems  to  systems  at  other  nodes,  but  the  expanded 
version  contains  information  on  source  and  destination  node  activity,  function,  and  protocol  as 
well.  The  top  portion  of  Table  4-6  shows  the  source  node,  systems,  and  fiinctions  that  produce 
the  required  information  element,  while  the  bottom  portion  of  the  table  shows  the  consumer 
node,  systems,  and  functions  as  well  as  the  inter-nodal  transport  necessary  to  convey  the 
information.  This  view  provides  enough  information  to  assess  the  current  state  of  FoS 
interoperability  as  well  as  future  requirements. 

The  expanded  Systems  Information  Exchange  Matrix  is  derived  from  the  Operational 
Information  Exchange  Matrix  (OV-3),  the  Technical  Architecture  Profile  (TV-1),  the 
Operational  Activity  to  System  Traceability  Matrix  (SV-3b),  and  the  Systems^  Matrix  (SV-3c). 
This  makes  the  Systems  Information  Exchange  Matrix  the  system  analog  to  the  Operational 
Information  Exchange  Matrix  (OV-3).  The  expanded  Systems  Information  Exchange  Matrix  can 
be  derived  because  the  matriees  of  the  preceding  architecture  products  can  be  used  to  create  end- 
to-end  views  of  system  information  and  service  exchanges.  These  end-to-end  views  were  built 
using  the  information  presented  previously  in  Tables  4-1  through  4-5.  Each  communication  and 
exchange  of  service  between  two  systems  can  trace  the  capabilities,  activities,  functionality,  and 
logical  and  technical  interfaces  of  the  architecture. 

Architecture  Assessments 

To  conduct  the  architecture  assessment,  it  is  helpful  to  assess  the  system  sequencing,  or  the  order 
in  which  the  events  in  a  particular  scenario  may  occur.  Table  4-7  provides  a  possible  system 
sequence  for  the  Precision  Engagement  example.  The  Systems  Information  Exchange  Matrix 
lines  are  ordered  from  1  to  16,  representing  the  possible  order  in  which  each  would  occur.  Each 
of  these  lines  is  also  mapped  to  the  Operational  Activity/Trace  Diagram  (OV-6c)  interface 
identifier  in  the  second  column  of  the  table.  By  showing  the  system  sequence  along  with  the  lEs, 
the  system  function  that  produced  the  lEs,  and  the  candidate  systems  that  may  perform  the 
system  functions,  it  is  possible  to  determine  additional  interaction  that  may  be  necessary  between 
nodes  in  order  to  accomplish  the  mission.  For  example.  Sequence  Lines  6  through  1 1  all  map  to 
the  same  operational  interface  (Number  5)  in  the  Operational  Activity/Trace  Diagram.  Close 
examination  reveals  that  the  collection  plan  for  the  Guardrail  must  first  go  to  the  Control  Node 
because  it  is  a  tactieal  asset,  but  the  same  information  can  travel  directly  from  the  JFACC  to  the 
future  high-altitude  UAV,  because  the  UAV  is  a  theater  asset.  By  reviewing  the  systems 
sequencing  in  this  manner,  the  systems  architect  can  begin  to  assess  the  interoperability  of  the 
FoS  architecture. 
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Table  4-6 

Expanded  Systems  Information  Exchange  Matrix  (SV-6c) 


OV-6c 
Int.  ID 

Source  Node 

Source  Node 

IE 

Activity 

Source  System 

Source  System 
Function 

Source  System 
Protocol 

1 

NTM 

Sensor  Reports 

TCPED 

NTM 

TCPED 

NITF,  USMTF 

4 

NTM 

Sensor  Reports 

TCPED 

NTM 

TCPED 

NITF,  USMTF 

2 

Theater 

Command 

Collection 

Reqs. 

Issue  Task 
Ord./Guid. 

JDISS 

Task  Sensors 

USMTF 

3 

Theater 

Command 

Task 

Order/Guid. 

Issue  Task 
Ord./Guid. 

JTF  TBMCS,  GCCS 

Update  Mission 

Plan 

USMTF 

7 

Op.  Command 

Wpn.  Tgt.  Plan 

Update  Mission 

Plan 

JFACC  GCCS 

Weapon  Target 
Assoc. 

USMTF 

5 

Op.  Command 

Mission  Plan 

Deconflict 

Airspace 

JFACC  TBMCS 

Air  Pic.  Int./Dyn. 
Deconflict. 

USMTF 

5 

Op.  Command 

Collection  Plan 

Update  Mission 

Plan 

JFACC  GCCS 

Collection  Planning 

USMTF 

6 

Op.  Command 

Permission  to 

Fire 

Grant  Perm,  to 

Fire 

JFLCC  GCCS 

Decision,  Tgt. 
Priority 

USMTF 

8 

Detect 

(Guardrail) 

Sensor  Reports 

Detect 

Tgt. /Environ. 

Guardrail  CTT 

Single  Sensor 

Sense 

USMTF 

8 

Detect  (UAV) 

Sensor  Reports 

Detect 

Tgt. /Environ. 

UAV 

SYERS/ASAS/IRIS 

Single  Sensor 

Sense 

Binary 

5 

Control 

Collection  Plan 

Control 

GSM  UHF  Radio 

Collection 

Execution 

Voice 

5 

Control 

Collection  Plan 

Control 

CARS/DCGS 

Collection 

Execution 

Binary 

9 

Control 

Target 

Nomination 

Nominate  Target 

TOC  GCCS 

Decision,  Tgt 

Priority 

USMTF 

10 

Control 

Fire  Order 

Issue  Fire  Order 

TOC  AFATDS 

Issue  Fire  Order 

USMTF 

11 

Engage 

Wpn.  Launch 

Rpt. 

Weapon  Fly-Out 

MLRS  FDC 

AFATDS 

Wpn.  Init.  and 
Launch 

USMTF 

OV-6c 
Int.  ID 

Destination  Node 

Inter-nodal 

Transport 

Destination 

Node 

Activity 

Destination  System 

Dest.  System 
Function 

Dest.  System 
Protocol 

1 

IBS 

Theater  Com. 

Issue  Task 
Order/Guid. 

JDISS 

Decision  Planning 

NITF,  USMTF 

4 

IBS 

Control 

ID  Target 

TOCCTT,ASAS, 

TROJAN 

ID  Target 

NITF,  USMTF 

2 

JWICS 

NTM 

TCPED 

NTM 

Multi- Sensor 

Sense 

USMTF 

3 

SIPRNet, 

JWICS 

Op.  Command 

Update  Mission 

Plan 

JFACC  TBMCS,  GCCS 

Update  Mission 

Plan 

USMTF 

7 

SIPRNet 

Control 

Issue  Fire  Order 

TOC  AFATDS 

Issue  Fire  Order 

USMTF 

5 

SIPRNet 

Control 

Control 

TOC  GCCS 

Mission  Execution 

USMTF 

5 

SIPRNet, 

JWICS 

Control 

Control 

TOC  GCCS 

Mission  Execution 

USMTF 

6 

SIPRNet, 

JWICS 

Control 

Issue  Fire  Order 

TOC  AFATDS 

Issue  Fire  Order 

USMTF 

8 

CDL 

Control 

ID  Tgt./Geolocate 
Tgt. 

GSM  ASAS 

Multi-Sens.  Sense, 
Feat.  Ext. 

USMTF 

8 

CDL 

Control 

ID  Tgt./Geolocate 
Tgt. 

GSM  ASAS,  TROJAN 

Multi-Sens.  Sense, 
Feat.  Ext. 

Binary 

5 

UHF  LOS 

Radio 

Detect 

(Guardrail) 

Detect 

Tgt./Environ. 

Guardrail,  UHF  Radio 

Single  Sensor 

Sense 

Voice 

5 

CDL 

Detect  (UAV) 

Detect 

Tgt./Environ. 

UAV 

SYERS/ASARS/IRIS 

Single  Sensor 

Sense 

Binary 

9 

SIPRNet 

Op.  Command 

Grant  Perm,  to  Fire 

JFACC  GCCS 

Dec.,  Tgt. 
Prioritization 

USMTF 

10 

MSB 

Engage 

Weapon  Fly-Out 

MLRS-FDC,  AFATDS, 
ATACMS 

Wpn.  Init.  and 
Launch 

USMTF 

11 

MSB 

Op.  Command 

Update  Mission 

Plan 

JFACC  AGCCS 

Collection 

Planning 

USMTF 

Table  4-7 

System  Sequencing 
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The  systems  architecture  team  begins  the  interoperability  assessments  by  reviewing  each  line  in 
the  Extended  Systems  Information  Exchange  Matrix  (SV-6),  taking  into  consideration  each  of 
the  following  questions: 

•  Does  the  line  describe  an  as-is  or  to-be  status? 

•  Do  the  specified  systems  provide  the  required  functionality? 

•  Do  the  systems  on  each  line  process  the  required  information,  and/or  are  they  integrated? 

•  If  the  line  reflects  an  as-is  status,  are  there  any  known  interoperability  issues? 

•  If  the  line  reflects  an  as-is  status,  have  the  systems  interfaces  been  certified? 

Each  line  in  the  SV-6  is  the  integration  requirement  for  the  given  operational  concept.  As  such,  it 
is  important  to  recognize  the  “as-is”  or  “to-be”  status  of  each  line.  For  clarification  purposes,  an 
“as-is”  line  describes  program  of  record  systems  beyond  Milestone  B,  or  possibly  some  systems 
that  have  been  demonstrated  in  Advanced  Concept  Technology  Demonstrations  (ACTDs).  “To- 
be”  systems,  on  the  other  hand,  are  defined  as  concept  systems.  This  distinction  is  important 
because  the  “as-is”  systems  provide  the  baseline  interoperability,  performance,  and  capability 
data.  From  this  baseline,  concept  or  “to-be”  systems’  interoperability,  performance,  and 
capability  can  be  extrapolated. 

It  is  also  important  to  note  that  that  the  SV-6  line  assessments  involve  consideration  of  a  desired 
requirement  for  interoperability,  performance,  and  capability,  not  verification  of  performance  or 
contribution  to  capability.  The  examples  shown  previously  in  Table  4-6  are  all  considered  “as-is” 
lines  from  an  integrated  perspective  and  can  be  used  to  provide  a  baseline  architecture  concept. 
The  “as-is”  and  “to-be”  integration  status  prefaces  all  remaining  questions  regarding  how  to 
access  data  and  how  confidence  is  derived  in  the  assessments.  Operationally,  however,  the  direct 
flow  of  information  from  the  Engage  node  to  the  Operational  Command  node  is  a  “to-be” 
concept.  Normally,  this  flow  of  information  goes  up  through  the  Command  node  and  then  to  the 
Operational  Command  node.  For  the  sake  of  illustration,  the  sensing  functions  in  the  SV-6  table 
are  based  on  “as-is”  systems  and  systems  functions. 

System-to-system  functional  mapping  assessments  start  with  review  of  existing  documentation 
from  Mission  Need  Statements  (MNSs),  Operational  Requirements  Documents  (ORDs), 
Functional  Descriptions,  Interface  Descriptions,  and  data  collected  from  previous  tests  and 
architecture  assessments.  At  the  level  of  detail  in  Table  4-6,  all  systems  are  assessed  to  be 
capable  of  performing  the  required  system  functions.  It  is  again  important  to  note  that  no  effort 
was  made  to  validate  that  systems  are  optimized  in  an  engineering  sense;  rather,  the  table 
provides  evidence  of  baseline  functionality  as  a  starting  point  toward  achieving  the  full  benefits 
of  the  NCW  concept. 

When  the  lines  in  the  expanded  Systems  Information  Exchange  Matrix  in  Table  4-6  are  assessed 
for  their  ability  to  process  the  desired  information  and  level  of  integration,  some  interesting  areas 
requiring  further  investigation  are  revealed.  For  example,  for  the  System  Information  Exchange 
Matrix  lines  showing  system  integration  requirements  between  GCCS  and  Army  Field  Artillery 
Tactical  Data  System  (AFATDS),  no  documentation  could  be  found  showing  that  these  systems 
have  been  interfaced;  rather,  operator  intervention  may  be  required  at  an  operator  console.  This 
is  not  a  problem,  but  it  should  be  recognized  with  regard  to  the  level  of  FoS  integration. 

Tracking  the  interoperability  issues  requires  checking  the  Troubled  Systems  Lists,  Casualty 
Reports,  and  a  variety  of  data  from  test  commands.  While  several  systems  in  the  Systems 
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Information  Exchange  Matrix  in  Table  4-6  were  found  to  have  minor  system  issues,  none  was 
associated  with  the  context  of  this  operational  concept  or  information  exchange. 

Each  service  has  a  technical  test  command  and  interoperability  agencies  that  certify  systems  and 
interfaces  to  be  interoperable  to  some  level.  The  Joint  Interoperability  Test  Command  (JITC)  is 
responsible  for  overall  Joint  certification.  Databases  from  individual  test  and  interoperability 
agencies  as  well  as  JITC  are  typically  reviewed  to  determine  the  existence  of  certifications  for 
each  system,  system  interface,  and  inter-nodal  transport.  For  the  systems  in  Table  4-6,  this 
assessment  found  that  all  mature  systems  were  certified. 

To  illustrate  how  results  are  derived  using  this  type  of  assessment,  consider  that  the  expanded 
Systems  Information  Exchange  Matrix  (SV-6)  presented  in  Table  4-6  was  found  to  present 
moderate  interoperability  risk  in  the  context  of  the  NCW  operational  concept.  While  the  systems 
within  each  Battle  Functional  Area  (BE A)  were  revealed  to  be  integrated  and  interoperable,  areas 
in  which  BE  As  were  traversed  (e.g..  Intelligence  (ASAS)  to  Fires  (AFATDS))  could  be  assessed 
as  presenting  greater  interoperability  risk  due  to  undefined  interfaces.  Similarly,  where  tactical 
control  of  an  asset  was  separated  from  operational  control  of  that  same  asset,  the  required 
interaction  and  the  systems  integration  also  presented  higher  levels  of  interoperability  risk. 

The  value  in  this  type  of  architecture  assessment  is  threefold: 

•  It  provides  the  ability  to  baseline  the  operational  concept  within  the  context  of  given 
architecture  framework  products. 

•  It  enables  architects  to  extrapolate  interoperability,  performance,  and  capability  data  for  “to- 
be”  operational  concepts. 

•  It  provides  assistance  in  developing  systems  requirements. 

These  benefits  give  the  warfighter,  architect,  and  engineer  a  common  framework  for  exchanging 
and  communicating  end-to-end  requirements.  Further,  the  warfighter,  architect,  and  engineer  can 
all  optimize  their  perspectives  (e.g.,  operational,  system,  performance  improvements, 
interoperability,  etc.)  through  recomposition  of  activities,  systems,  functions,  sensors,  platforms, 
and  C2  to  assess  the  impact  to  warfighter  capability  and  outcomes. 

FoS/SoS  Concepts  versus  Classical  Systems  Engineering 

This  chapter  has  used  military  doctrine  and  the  specification  of  actual  systems  to  impart  a  more 
detailed  understanding  of  the  architecture  abstracted  in  Chapter  3  through  the  instantiation  of 
those  abstractions.  The  architecture  views  presented  in  this  chapter  for  a  hypothetical  case  study 
that  incorporates  a  mix  of  legacy  and  possible  future  Army/ Air  Force  systems  closely  parallel  the 
Navy  work  in  targeting  that  will  be  discussed  in  the  next  chapter.  The  Precision  Engagement 
example  in  this  chapter  and  its  architectural  description  were  chosen  for  their  simplicity.  Even 
with  the  addition  of  NTM,  there  are  only  1 1  nodal  connections  to  be  made  in  the  Operational 
Event/Trace  Description  (OV-6c).  By  contrast,  the  targeting  architecture  used  by  the  Navy  for 
the  POM  04  and  PROS  analyses  included  39  end-to-end  mission  threads  and  2,857  identified 
nodal  connections. 

Summary 

The  abstract  nodal  architecture  developed  in  Chapter  3  can  be  instantiated  with  the  FoS  used  in 
the  Precision  Engagement  example.  The  FoS  is  seen  to  have  adequate  functionality  and 
connectivity  to  support  the  Precision  Engagement  capability. 
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CHAPTER  5 

FLEET  BATTLE  EXPERIMENT  INDIA  TIME  SENSITIVE  TARGETING 
Purpose 

The  Precision  Engagement  Case  Study  in  the  previous  chapter  focused  on  how  the  first  three 
architecture  product  groups  can  be  used  in  analyzing  the  ability  of  an  FoS  to  deliver  a  specific 
capability.  This  chapter  presents  another  case  study,  Fleet  Battle  Experiment  -  India  (FBE-I) 
Time  Sensitive  Targeting  (TST),  which  focuses  on  how  alternative  systems  that  could  instantiate 
the  architecture  can  be  assessed  in  order  to  build  an  acquisition  plan.  It  focuses  on  the  fourth 
architecture  product  group,  Acquisition  Planning.  This  chapter  will  provide  the  reader  with  a 
better  understanding  of  the  need  for  alignment  of  systems  in  their  procurement  schedules  to 
ensure  the  inclusion  of  resources  for  the  FoS  systems  engineering  and  integration  that  will  enable 
the  interoperation  of  the  systems  in  the  family. 

Background 

FBEs  are  a  Chief  of  Naval  Operations  (CNO)  initiated  series  of  experiments  designed  to 
investigate  Network  Centric  Operation  as  a  framework  for  development  of  new  doctrine, 
organizations,  technologies,  processes,  and  systems  for  fixture  warfighting.  Experiments  are 
designed  to  address  near-  and  long-term  service  warfighting  issues  in  a  Joint  context  using  likely 
future  threat  scenarios.  The  Navy  Warfare  Development  Command  (NWDC)  is  the  CNO’s  agent 
for  planning  and  implementing  these  experiments  in  partnership  with  the  numbered  fleets.  FBE-I 
was  the  ninth  in  the  FBE  series. 

The  vision  of  FBE-I  was  to  “operationalize”  NCW  by  building  and  maintaining  a  C4ISR 
architecture  that  provided  Joint  forces  with  wide  area  connectivity,  enhanced  bandwidth,  and 
reach-back  capability.  The  experiment  focused  on  three  primary  areas: 

•  Providing  Joint  Fires  in  support  of  maneuvers,  including  TST,  operational  maneuver  from  the 
sea,  and  ship-to-objective-maneuver 

•  Delivering  assured  access  and  optimization  of  the  littoral  Anti-Submarine  Warfare  (ASW) 
force  warfighting  capability  by  establishing  real-time  connectivity  between  the  C4I 
architecture  and  a  submarine 

•  Assessing  Information  and  Knowledge  Advantage  (IKA)  provided  by  the  ability  to  build  and 
maintain  the  network-centric  C4ISR  architecture 

The  experiment  was  conducted  as  part  of  the  overarching  Pacific  Command  (PACOM)- 
sponsored  exercise  Kernel  Blitz  and  was  coordinated  by  Commander  Third  Fleet. 

For  the  Joint  Fires  portion  of  the  experiment,  the  ASN  RDA  Chief  Engineer  (CHENG) 
conducted  architecture  analysis.  The  FBE-I  Joint  Fires  TST  architecture  analysis  effort  had  three 
specific  objectives: 

•  Provide  NWDC  with  engineering  experience  and  discipline  in  documenting,  recording,  and 
analyzing  FBE-I  TST  technical  and  system  functional  architecture  views 

•  Evaluate  the  architecture  analysis  process  used  by  CHENG  in  this  experiment  as  proof  of 
concept  to  institutionalize  the  CHENG  approach  for  continued  use 
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•  Identify  key  performance  system  integration  solutions  for  TST  that  impact  mission  capability 
and  evaluate  the  possible  acquisition  of  those  solutions  for  the  Fleet 
The  results  of  the  experiment  were  used  to  support  the  development  of  an  investment  strategy  in 
POM  04  to  improve  strike  capabilities. 

FBE-I  Operational  Concept 

To  describe  the  FBE-I  Operational  Concept,  an  Operational  View  and  an  Activity  Model  were 
developed.  Details  on  the  architecture  products  developed  to  support  the  FBE-I  Operational 
Concept  are  presented  in  the  following  paragraphs. 

High-Level  Operational  Concept  (OV-1) 

Figure  5-1  is  the  Operational  View  1  (OV-1)  depicting  the  general  concept  of  the  experiment. 
The  OV-1  used  in  FBE-I  also  included  a  detailed  narrative  that  described  the  concept  of 
operations  used  in  the  Joint  Fires  portion  of  the  FBE-I  experiment,  but  due  to  its  length,  that 
narrative  has  not  been  included  in  this  example.  In  general,  the  objective  of  the  Joint  Fires 
portion  of  FBE-I  was  evaluation  of  the  concept  of  using  Joint  Fires  in  support  of  Land 
Maneuver.  As  shown  in  Figure  5-1,  this  portion  of  the  experiment  involved  the  Marines  launch 
of  a  Littoral  Penetration  Task  Force  (LPTF)  that  was  attempting  to  maneuver  to  the  objective 
(indicated  by  the  red  triangle).  In  order  to  defeat  an  opposing  enemy  threat,  surface  weapons 
(e.g..  Extended  Range  Guided  Munitions  (ERGMs),  Land  Attack  Standard  Missiles  (LASMs), 
Tactical  Tomahawk  Land  Attack  Missiles  (TTLAMs),  and  Advanced  Land  Attack  Missiles 
(ALAMs))  would  be  likely  to  require  rapid  retargeting  data,  and  Tactical  Air  (TACAIR)  assets 
could  require  in-flight  redirection.  The  network  provided  in  the  experiment  would,  in  theory, 
provide  the  timely  information  required  to  influence  the  maneuver  ashore. 


Figure  5-1.  FBE-I  TST  Joint  Fires  Operational  View  (OV-1) 
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Activity  Model 

Figure  5-2  provides  the  Joint  Targeting  Doctrine  augmented  for  TST.  This  doctrine  was  used  as 
the  basis  for  the  FBE-I  TST  Joint  Fires  Operational  Concept.  In  the  graphic,  the  various  aspects 
of  targeting  are  integrated  into  a  unified  model.  This  activity  model  is  traceable  to  the  Joint 
Targeting  Doctrine  for  the  Precision  Engagement  example  presented  in  Chapter  4  (Figure  4-3). 
The  main  difference  is  an  inner  loop  for  TST  that  is  triggered  by  observations  made  either  locally 
or  through  TCPED  during  the  execution  of  the  planned  mission.^ 


Figure  5-3  is  the  modified  Activity  Diagram  (OV-6c)  that  captures  the  notional  decomposition  of 
activities  associated  with  the  TST  experiment  in  FBE-I.  It  is  a  hierarchical  depiction  of  the 
CONOPs-developed  list  of  activities.  The  first  tier  activities  (Detect,  Decide,  Engage,  Assess) 
provide  the  most  basic  description  of  how  TST  was  accomplished  in  FBE-I.  (Note  that  an 
additional  Prepare  phase  was  provided  in  the  background,  but  that  phase  was  not  in  the  scope  of 


^This  model  was  developed  by  the  Naval  Targeting  Operational  Architecture  team.  The  development  conducted  by 
this  team  was  a  collaborative  effort  with  participation  from  across  the  Fleet  and  OPNAV.  The  team  was  led  by  Dr. 
Cheryl  Walton  (who  was  the  RDA  CHENG  Deputy  Director  of  Architectures  at  that  time)  and  BGen  (ret)  Bruce 
Byrum. 
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the  FBE-I  CONOPS.)  The  second  tier  activities  (e.g.,  Receive  TST  Cue,  Assess,  etc.)  are  more 
detailed  descriptions  of  how  the  first  tier  activities  will  be  accomplished.  Finally,  the  third  tier 
activities,  which  were  drawn  from  the  Universal  Naval  Task  List/Naval  Tactical  Task  List  [11] 
vice  the  CONOPs,  were  used  to  cross-reference  the  first-  and  second-tier  activities  in  FBE-I  to 
approved  Naval  Tasks. 


Prepare 


UNCLASSIFIED 


Figure  5-3.  Modified  Activity  Diagram  (OV-6c)  for  the  TST  Experiment  in  FBE-I 


The  Activity  Flow  Diagram  served  as  a  basis  for  comparing  alternative  systems.  By  transferring 
the  concept  of  operations  into  a  detailed  Activity  Flow  Diagram,  it  was  then  possible  to  map  the 
activities  to  specific  systems  fiinctions.  Once  the  system  functions  are  identified,  they  can  be 
mapped  to  the  desired  activities  with  specified  time  limits  (represented  by  tO  through  t4).  It  is 
then  possible  to  map  the  systems  that  support  those  activities  and  functions  in  order  to  identify 
where  alternatives  may  exist  for  particular  activities  and/or  functions. 


FBE-I  System  Functional  Mapping 

To  provide  a  stable  model  to  facilitate  management  of  the  complex  information  describing  the 
systems,  their  relationships,  and  their  evolution,  a  System  Functionality  Description  and 
Operational  Activity  to  System  Function  to  System  Mapping  were  developed.  Details  on  the 
architecture  products  developed  to  support  the  FBE-I  System  Functional  Mapping  are  presented 
in  the  following  paragraphs. 


This  model  was  developed  under  the  leadership  of  Scott  Millet  at  the  Naval  Air  Weapons  Center,  China  Lake, 
CA. 
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System  Functionality  Description 

Table  5-1  provides  the  Second-Level  Systems  Functions  List  for  the  architecture.  System 
functions  are  defined  as  the  steps  taken  by  hardware  or  software  to  complete  a  process.  These 
functions  act  in  concert  with  the  activities  described  in  the  Activities  Diagram  in  Figure  5-2  and 
together  represent  the  steps  taken  by  people  and  organizations  to  complete  a  process.  The 
functions  listed  below  served  as  a  starting  point  for  the  mapping.  Higher  levels  of  fidelity  in  the 
systems  functions  were  used  to  complete  the  mapping  to  the  actual  systems  that  supported  the 
activities.  Table  5-1  lists  the  second  level  functions  used  before  the  move  to  the  next  level  of  fidelity. 


Table  5-1 

Second-Level  Systems  Functions  List  (SV-4a) 


First-Level 

Functions 

Second-Level 

Functions 

Definitions 

Sense 

Single  Sensor  (SS) 
Sense 

Functions  that  perform  detection,  identification,  and  development 
of  imagery,  track,  and  parametric  data  by  a  single  sensor  on 
objects  in  area  of  interest 

Multi-Sensor  (MS) 
Sense 

Functions  that  create  and  maintain  a  correlated  and  fused  common 
sensor  picture  from  multi-sensor  data 

Command 

Situational 
Assessment  (SA) 

Functions  that  generate  a  common  tactical  picture  and  provide 
awareness  of  the  tactical  situation,  including  engagement  status 
reporting,  battle  damage  reporting,  and  warning  reports  to  support 
planning  and  decision-making 

Plan  (P) 

Functions  that  allocate  assets,  determine  coverage  requirements, 
assign  areas  of  responsibility,  develop  platform  movement  orders, 
and  determine  sensor  and  weapon  system  configurations  required 
to  execute  a  mission 

Decision  (D) 

Functions  that  support  the  development  of  engagement  orders 
including  threat  prioritization,  development  of  fire  control 
solutions,  target- weapon  pairing,  and  dynamic  deconfliction 

Act 

Engagement 
Execution  (EE) 

Functions  necessary  to  execute  an  engagement  (electronic  attack, 
platform/weapon  fly-out)  and  to  collect  information  to  support 
combat  assessment 

Force  Positioning 
(FP) 

Functions  necessary  to  deploy,  maneuver,  sustain,  and/or 
configure,  platforms,  troops,  cargo,  sensors,  and  weapons 

Interoperate 

Communicate  Sense 
Data  (CSD) 

Functions  that  support  the  dissemination,  including  formatting,  access 
and  routing,  of  sensor  data  which  is  to  include  detection  or  track  data, 
signal  feature  or  ID  data,  or  imagery  data 

Communicate  Force 
Orders  (CFO) 

Functions  that  support  the  dissemination,  including  formatting, 
access,  and  routing,  of  rules  of  engagement,  target  lists, 
intelligence,  and  restricted  areas 

Communicate  Status 
(CS) 

Functions  that  support  the  dissemination,  including  formatting, 
access,  and  routing,  of  engagement  results  and  status,  including 
imagery  and  mission  and  operations  status 

Communicate  Order 
(CO) 

Functions  that  support  the  dissemination,  including  formatting, 
access,  and  routing,  of  calls  for  fire,  weapon  tasking,  aim-point 
data,  disarming  orders,  warning  orders 

Precision  Navigation 
and  Timing  (PNT) 

Functions  that  supply  current  time,  navigation  data,  and 

METOC  data  to  all  other  functions 
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Operational  Activity  to  System  Function  to  System  Mapping 

Figure  5-4  provides  the  Activity  Flow  Diagram,  with  mapping  of  functions  and  systems  to  each 
operational  activity.  The  activity  flow  diagram  established  for  this  notional  task  is  framed  hy  the 
activities  written  in  each  box.  In  the  comer  of  the  box  is  a  number  that  represents  the  system 
function  that  maps  to  the  activity  in  the  box.  There  is  also  a  system  with  a  number  that  is  mapped 
to  each  box.  Each  system  number  represents  an  actual  system  that  can  and  has  been  used  to 
perform  the  activity  and  function  in  each  box.  As  shown  in  the  figure,  the  same  system  may 
perform  several  of  the  activities  and  functions.  In  some  cases,  several  systems  are  identified  that 
are  capable  of  performing  the  same  function;  in  other  cases,  there  are  no  systems  available  to 
perform  the  function. 


The  Activity  Flow  Diagram  in  Figure  5-4  provides  a  critical  mapping  of  operator  activities, 
systems  functions,  and  systems  that  can  allow  users  to  see  where  possible  overlaps  and  gaps  may 
exist  in  the  end-to-end  process.  It  should  be  noted  that  this  is  only  an  initial  indication  of  the 
existence  and  location  of  possible  overlaps  and  gaps;  further  analysis  must  be  conducted  in  order 
to  identify  where  necessary  and  unnecessary  duplication  may  exist  and  where  there  may  be 
desired  gaps  in  system  coverage.  For  example,  in  combat  operations,  there  is  often  the  need  for 
designed-in  redundancy  to  increase  the  probability  of  success.  Additionally,  combat  has  certain 
aspects  that  demand  that  intervention  and  processing  be  performed  by  human  beings  rather  than 
systems;  accordingly,  certain  activities  may  be  intentionally  unaligned  with  systems  to  perform 


support  for  that  activity. 


System  12 


System  26 


System  27 
System  28 


System  29 


Figure  5-4.  Activity  Flow  Diagram  with  Function  and  Systems  Mapping 
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While  this  mapping  only  provides  an  initial  look  at  possible  gaps  and  overlaps,  it  is  a  helpful  tool 
for  determining  areas  for  further  investigation.  The  notional  results  of  the  functional  analysis  can 
be  presented  in  the  manner  shown  in  Figure  5-5. 


At  first  glance,  it  is  clear  that  there  are  initial  indications  of  possible  gaps  and  overlaps  that  merit 
further  analysis.  If  the  analysis  indicates  that  there  is  unnecessary  overlap  based  on  an  accepted 
level  of  risk  to  the  stakeholder,  then  further  analysis  should  be  conducted  to  determine  if  the 
system  is  required.  This  analysis  should  begin  with  an  assessment  of  the  system  in  the 
performance  of  the  specific  activity  and  function,  but  beyond  this  assessment,  there  are  several 
sensitivities  that  must  be  considered  before  a  final  decision  can  be  made  to  determine  if  the 
duplicate  system  is  required. 

It  is  important  to  note  that  because  systems  are  often  procured  based  on  individual  assessments 
of  a  single  system  in  the  areas  of  cost,  schedule,  and  performance,  the  procurement  of  systems 
that  can  perform  overlapping  functions  is  not  unusual.  Until  a  system  of  systems  is  evaluated 
against  the  objective  operational  architecture,  the  impact  of  the  overlaps  cannot  be  fully  realized. 
Further,  the  failure  to  evaluate  systems  of  systems  against  an  objective  operational  architecture 
has  resulted  in  a  trend  of  investing  in  the  improvement  of  systems  that  have  proven  to  be  capable 
of  conducting  certain  functions,  and  this  trend  has  resulted  in  the  acquisition  of  multiple  systems 
that  can  conduct  these  certain  functions.  Meanwhile,  little  investment  has  been  made  in  new 
systems  that  are  required  to  fill  gaps.  Additionally,  new  systems  that  are  procured  are  frequently 
not  fully  interoperable  with  their  respective  system  of  systems,  into  which  significant  investment 
has  already  been  made.  This  fact  makes  achieving  end-to-end  interoperability  nearly  impossible. 

The  architecture  analysis  conducted  as  part  of  FBE-I  was  designed  to  show  how  the  architecture 
products  could  be  used  to  evaluate  systems  of  systems  against  an  objective  operational 
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architecture.  The  results  of  FBE-I  were  used  to  assess  the  performance  of  systems  in  an  end-to- 
end  process  to  achieve  the  concept  of  operations  described  previously  in  Figure  5-1.  For  the  set 
of  systems  used  in  FBE-I,  actual  experiment  data  was  recorded  to  indicate  the  end-to-end 
performance  as  well  as  the  individual  system  performance  in  the  specified  task  and  scenario. 
This  process  yielded  an  objective  activity  flow  diagram  mapped  to  a  desired  set  of  system 
functions  and  mapped  to  a  set  of  systems  that  were  going  to  be  used  for  the  experiment.  It  was 
then  possible  to  map  multiple  programs  of  record  to  the  same  desired  operational  activities  and 
functions,  providing  an  indication  of  the  existence  of  other  systems  capable  of  performing  those 
same  functions.  The  addition  of  these  systems  from  programs  of  record  enabled  identification  of 
potential  overlaps  and  gaps.  In  cases  where  overlaps  were  identified,  additional  analysis  was 
conducted  to  see  if  the  overlap  was  a  necessary  or  unnecessary  duplication. 


During  POM  04  decision-making.  Navy  personnel  used  architectures  to  develop  a  gaps  and 
overlaps  analysis  like  the  one  shown  previously  in  Figure  5-5.  The  results  of  this  analysis 
provided  pointers  for  more  detailed  systems  engineering  trades  that  enabled  determination  of 
whether  or  not  overlaps  were  indeed  duplications  and  allowed  assessment  of  the  operational 
impact  of  system  functional  gaps.  The  process  is  summarized  in  Figure  5-6. 
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Figure  5-6.  Analysis  Process  used  for  POM  04 


FBE-I  System  Interface  Mapping 

To  gain  a  better  understanding  of  the  connectivity  between  FBE-I  systems,  a  system  interface 
mapping  was  developed.  Details  on  the  architecture  products  created  to  support  this  area  of  the 
analysis  are  described  in  the  following  paragraphs. 
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Systems  Interfaces  and  Connectivity 

A  system  interface  mapping  was  developed  in  order  to  conduct  the  experiment.  The  physical 
interfaces  set  up  for  the  experiment  were  leveraged  by  identifying  the  lERs  that  were  used  as 
well  as  the  standards  and  protocols  applied.  Figure  5-7  provides  a  notional  description  of  the 
physical  interfaces  that  were  used.  This  system  interface  mapping  represents  the  physical 
platforms  and  systems  that  were  used  to  support  the  activity  and  function  flow  diagram  presented 
previously  in  Figure  5-3.  The  actual  database  stored  in  the  Joint  Mission  Area  Analysis  Tool 
(JMAAT)  enabled  drill-down  to  the  individual  systems  on  each  of  the  platforms  described.  The 
system  interface  mapping  was  used  as  a  baseline  to  enable  identification  and  evaluation  of  each 
system  for  its  ability  to  integrate  with  other  systems  and  to  support  the  required  functions  in 
order  to  meet  the  specifications  of  the  architecture.  This  mapping  also  led  to  identification  of 
systems  that  performed  duplicate  functions.  When  systems  were  identified  as  providing 
unnecessary  duplication  in  function,  further  analysis  was  conducted  to  determine  if  the  systems 
were  required  in  support  of  the  activity  and  function. 


Figure  5-7.  Notional  FBE-I  TST  Platform  and  Einks  Relationship  (SV-1) 
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System  Information  Exchange  Matrix  (SV-6) 

The  System  Information  Exehange  Matrix  (SV-6)  describes,  in  tabular  format,  information 
exchanges  between  systems  within  a  node  and  from  those  systems  to  systems  at  other  nodes.  The 
focus  of  the  System  Information  Exchange  Matrix,  however,  is  on  how  the  data  exchanges 
actually  are  (or  will  be)  implemented.  Including  system-specific  details  covering  such  technical 
characteristics  as  specific  protocols  and  data  or  media  formats  is  critical  to  understanding  the 
potential  for  overhead  and  constraints  introduced  by  the  physical  aspects  of  the  implementation. 


The  System  Information  Exchange  Matrix  can  be  adapted  for  use  in  the  FoS  system  engineering 
process  by  broadening  this  view  to  create  end-to-end  views  of  system  information  and  service 
exchanges.  This  expanded  System  Information  Exchange  Matrix  will  retain  the  attributes  of  the 
existing  framework  product,  which  includes  the  information  exchanges  within  a  node  and  from 
those  systems  to  systems  at  other  nodes.  The  expanded  matrix  can  be  easily  derived  from 
information  in  the  Operational  Information  Exchange  Matrix,  Technical  Architecture  Profile, 
Operational  Activity  to  System  Traceability  Matrix,  and  Systems  Matrix.  By  combining  the 
information  from  these  four  products,  the  expanded  System  Information  Exchange  Matrix 
becomes  the  system  analog  to  the  Operational  Information  Exchange  Matrix.  The  expanded 
matrix  product  can  be  created  because  the  matrices  of  the  preceding  architecture  products  can  be 
used  to  develop  end-to-end  views  of  system  information  and  service  exchanges.  Each 
communication  between  two  systems  can  be  traced  to  illustrate  the  source  and  destination  nodes, 
activities,  systems,  system  frinctions,  information  elements,  technical  standards,  and  attributes  of 
logical  and  technical  interfaces  of  the  FoS  architecture.  As  shown  in  Figure  5-8,  this  matrix  can 
then  be  used  to  identify  gaps  in  interoperability. 
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"igure  5-8.  Use  of  System  Information  Exchange  Matrix  for  Gap  Analysis 
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As  noted  previously,  in  a  complex  system,  it  is  the  interfaces  and  connections  that  provide 
unique,  value-added  FoS  functions.  The  added  value  (e.g.,  a  more  coherent,  integrated  picture  of 
the  Battlespace)  is  derived  from  the  interaction  among  components  rather  than  from 
contributions  of  the  individual  components.  The  expanded  System  Information  Exchange  Matrix 
defined  in  the  previous  paragraph  describes  the  complex  FoS  entirely  in  terms  of  its  “application- 
to-application”  interfaces.  These  logical  interfaces  (not  the  physical  interfaces)  are  associated 
with  both  the  information  elements  being  exchanged  (data)  and  the  system  function  (application) 
processing  the  data  on  either  end  of  the  interface.  Information  elements  exchanged  between 
systems  have  traceability  back  to  the  lERs  defined  in  the  operational  views  (particularly  in  the 
Operational  Node  Connectivity  Description  and  the  Operational  Information  Exchange  Matrix) 
because  these  information  elements  are  the  contents  of  the  lERs.  The  interaction  of  information 
elements  and  system  functions  together  provide  key  FoS  “services”  that  are  fundamental  for 
achieving  interoperability.  Interoperability  is  commonly  defined  as  the  ability  of  systems,  units, 
or  forces  to  provide  services  to  and  accept  the  same  from  other  systems,  units,  or  forces  and  to 
use  the  data,  information,  material,  and  services  so  exchanged  to  enable  them  to  operate 
effectively  together.^^ 

The  enhanced  System  Information  Exchange  Matrix  is  only  concerned  with  primary  system 
functions.  Primary  system  functions  have  at  least  one  input  and  at  most  one  output.  The  inputs 
are  information  elements  that  are  acted  upon  or  changed  in  some  way  by  the  primary  system 
function  to  create  the  output.  Primary  system  functions  are  distinguished  from  supporting  system 
functions  in  that  the  latter  are  typically  attributes  of  infrastructure  (or  supporting)  systems  that 
move  (e.g.,  route,  switch,  transmit)  information  but  do  not  change  the  content  or  context  of  the 
data.  Supporting  system  functions  do  not  act  upon  or  change  the  content  or  context  of  the 
information  element  as  it  is  moved  from  source  to  destination  (primary  system  functions). 
Multiple  supporting  systems  are  usually  required  to  support  a  single  logical  interface  (primary- 
to-primary  system  function  interface). 

It  is  critical  to  remember  that  a  primary  system  function  can  have  no  more  than  one  output.  If  it 
appears  that  a  primary  system  function  has  more  than  one  output  information  element,  then  the 
levels  of  abstraction  between  the  system  functions  and  the  products  of  the  system  functions  are 
inconsistent  and  require  reconciliation  by  the  FoS  architect.  The  requirement  to  have  only  one 
output  per  primary  system  function  is  important  for  the  integrity  of  the  architecture,  and  this 
importance  will  become  even  more  evident  later  in  the  discussion  of  executable  architectures. 

In  developing  the  System  Information  Exchange  Matrix,  the  System  Functions  can  be 
decomposed,  which  also  enables  the  decomposition  of  the  associated  information  elements. 
Ultimately,  a  standard  FoS  functional  view  along  with  standard  information  elements  can  be 
defined  for  each  mission  area  and  can  be  used  in  the  expanded  System  Information  Exchange 
views,  a  line  item  of  which  is  shown  in  Figure  5-9. 


T^igure  5-9.  Expanded  SV-6  Line  Item  with  Standard  System  Functions  and  Standard  Information 
Elements 
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System  Interface  Description  (SV-1) 

In  the  Architecture  Framework,  the  System  Interface  Description  (SV-1)  is  a  view  that  illustrates 
the  relationships  and  interdependencies  between  systems  by  linking  the  operational  and  system 
interface  views  of  the  architecture.  This  view  depicts  the  assignments  of  systems  and  their 
interfaces  to  the  nodes  and  need  lines  described  in  the  Operational  Node  Connectivity 
Description.  The  Operational  Node  Connectivity  Description  for  a  given  architecture  shows 
operational  nodes  (not  always  defined  in  physical  terms),  while  the  System  Interface  Description 
depicts  the  corresponding  systems  nodes.  Systems  nodes  include  the  allocations  of  specific 
resources  (e.g.,  people,  platforms,  facilities,  and  systems)  that  will  be  used  for  implementing 
specific  operations. 

While  a  System  Interface  Description  will  typically  provide  a  graphical  representation  of  many 
systems  and  their  interfaces,  there  is  also  a  relationship  between  the  System  Interface  Description 
and  the  Expanded  System  Information  Exchange  (SV-6).  Figure  5-10  has  been  used  to  illustrate 
the  descriptor  for  one  interface  in  the  FBE-I  FoS.  This  single  row  describes  two  systems,  the 
APY-6  radar  and  the  TES-Forward,  and  their  interface  in  the  context  of  accomplishing  a  specific 
mission  task  associated  with  TST.  The  system  functions  and  the  information  exchange  required 
are  a  direct  result  of  an  operational  requirement  defined  by  the  operational  views.  The  figure  also 
shows  that  there  are  two  physical  nodes,  the  Hairy  Buffalo  P-3  and  the  Coronado  Command 
Ship,  specified  in  the  interface.  At  the  highest  level,  a  physical  node  may  also  be  considered  a 
system  in  the  System  Interface  Description.  It  can  be  assumed  that  these  two  platforms  were 
selected  for  their  ability  to  support  specific  tasks  in  the  mission.  The  decision  to  assign  these 
tasks  to  these  two  platforms  also  influenced  what  system  functions  had  to  be  available  at  each 
node  and  limited  the  available  solutions  for  the  communication  between  functions  (as  illustrated 
by  the  Systems  Communications  Description  (SV-2)).  Once  the  nodes  for  supporting  a  mission 
activity  have  been  identified,  the  required  system  functions  can  be  identified  using  the  System 
Functionality  Description  (SV-4).  The  solution  for  moving  required  information  elements 
between  two  communicating  system  functions  differs  greatly  based  on  the  geographic  location  of 
the  node(s). 


Figure  5-10.  Illustration  of  a  Descriptor  for  One  Interface  in  the  FBE-I  FoS 
FBE-I  Performance  Assessment  Results 

To  quantify  fhe  impacf  of  the  FBE-I  results  on  capabilities-based  acquisition  planning,  individual 
system  assessments  were  conducted  using  a  Multi-Attribute  Analysis  process.  This  process 
enabled  systems  to  be  ranked  and  then  mapped  into  an  acquisition  investment  plan  that  showed 
funding  and  schedule  data  plotted  against  time  and  allowed  visualization  of  program 
dependencies  and  phasing  issues  in  a  Capabilities  Evolution  Description  (CED)  or  CV-6.  The 
incorporation  of  capability  analysis  and  the  Multi-Attribute  Analysis  are  described  in  this  section,  and 
the  CED  is  described  in  the  following  section  on  capability-based  acquisition  planning. 
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Incorporating  Capability  Analysis 

Capability  analysis  involves  the  measurement  of  an  individual  system’s  ability  to  perform 
required  functions  and  the  FoS’s  ability  to  satisfy  required  mission  capability  objectives.  As 
discussed  in  previous  chapters,  performance  and  effectiveness  can  be  measured  through 
modeling  and  simulation,  experiments,  or  properly  documented  operational  lessons  learned. 
Measuring  an  individual  system’s  performance  differs  greatly  from  measuring  FoS  performance. 
Individual  system  performance  can  be  measured  by  evaluating  actual  performance  against  well- 
defined  requirements  and  specifications.  FoS  performance  effectiveness,  however,  must  be 
measured  by  evaluating  the  FoS’s  ability  to  meet  mission  objectives.  This  method  of 
measurement  introduces  the  challenge  of  dealing  with  several  sensitivities.  For  FBE-I,  the 
capability  analyses  were  performed  at  the  classified  level  by  Naval  Weapons  Development 
Center  and  Naval  Air  Warfare  Center,  China  Lake,  CA. 

The  effectiveness  of  an  FoS  capability  analysis  is  dependent  upon  identifying  the  proper 
components  within  the  architecture  for  analysis  and  selecting  the  most  appropriate  architecture 
for  the  mission  area  environment.  In  other  words,  it  is  important  to  make  investment  decisions  to 
select  the  proper  systems  to  comprise  the  mission  capability  package  architecture,  but  it  is  also 
critical  to  select  an  appropriate  architecture  that  can  achieve  the  mission  capability  based  on  a 
balance  among  operator  requirements,  fiscal  constraints,  and  capability  tradeoffs.  These  tradeoffs 
can  be  affected  by  the  impact  of  both  non-material  and  material  solutions.  Changing  any 
component  of  Doctrine,  Organization,  Training,  Materiel,  Leadership,  Personnel,  and  Facilities 
(DOTMLPF)  can  have  a  major  impact  on  the  analysis  and  its  results. 

The  decisions  that  must  be  made  when  seeking  mission  capability  are  not  solely  dependent  on 
maximum  system  architecture  performance  in  achieving  the  mission,  but  also  on  the  tradeoffs 
among  other  non-material  solutions.  Simply  put,  it  may  become  a  decision  between  a  100 
percent  solution  versus  an  80  percent  solution  when  it  comes  to  balancing  operational 
requirements,  capabilities,  and  cost. 

System  Assessment  through  Multi-Attribute  Analysis 

The  first  few  chapters  of  this  book  discussed  the  development  of  architectural  views  for  selected 
cases  or  operational  situations  that  can  be  used  to  establish  a  framework  that  clearly  describes  the 
required  activities,  functions,  and  systems  that,  when  fully  integrated,  can  provide  the  desired 
mission  capability.  The  development  of  these  views  will  provide  the  basis  for  conducting 
architecture  assessments  to  support  Multi-Attribute  Analysis.  These  assessments  of  the 
Architecture  Framework  views  provide  analysts  with  another  tool  for  balancing  operator 
requirements  against  capability  achievement  and  fiscal  constraints  in  order  to  better  define 
choices.  They  also  provide  a  starting  point  for  the  systems  engineering  trade-off  analysis.  The 
architecture  assessments  for  Multi- Attribute  Analysis  are  critical  to  the  development  of  Mission 
Capability  Packages  that  support  operationally  sound,  technically  feasible,  and  cost-effective 
acquisition  decisions. 

During  FBE-I,  the  impact  of  an  individual  system  on  the  end-to-end  process  was  determined 
using  a  Multi- Attribute  Analysis  conducted  by  assessing  the  following  attributes: 
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•  Functional  Utility 

•  Fleet  and  Other  Issues 

•  Interoperability 

•  Alignment  with  Future  Vision 

•  OpSit  Utility 

•  Fiscal  Rank 

Where  necessary,  further  Engineering  Analysis  was  conducted  to  analyze  detailed  performance 
issues.  Figure  5-11  illustrates  the  Multi-Attribute  Analysis  approach  used  for  FBE-I,  and  Figure 
5-12  illustrates  the  ranking  process  used  to  perform  the  attribute  analysis  for  TST  Command  and 
Control  Systems  for  POM  04.  These  analyses  provided  a  system-by-system  ranking  for  each 
attribute  as  well  as  an  overall  ranking.  The  Multi-Attribute  Analysis  builds  on  the  gap  and 
duplication  analysis  to  balance  operator  requirements  against  FoS  capability  achievement  and 
cost.  The  six  attributes  listed  previously  have  been  found  to  be  fundamental  to  the  Multi- 
Attribute  Analysis  process.  Each  of  these  attributes  is  illustrated  in  Figure  5-11  and  is  described 
in  the  paragraphs  that  follow  Figures  5-11  and  5-12. 


Figure  5-11.  Multi- Attribute  Analysis  Approach  Used  for  FBE-I 


Using  Architectures  for  Research,  Development,  and  Acquisition 


83 


The  first  attribute  used  in  the  Multi-Attribute  Analysis  process  is  an  assessment  of  functional 
utility.  Evaluation  of  this  attribute  involves  determining  whether  or  not  the  system  can  perform 
the  required  functions  defined  by  the  architecture  framework  System  Views  and  derived  from  the 
required  operator  activity  Operational  Views.  If  the  system  is  capable  of  performing  these 
functions,  it  remains  in  consideration. 

Once  the  system  has  been  determined  to  be  capable  of  performing  its  required  functions,  its 
ability  to  perform  other  functions  is  assessed  in  the  second  attribute  of  the  analysis.  It  is  critical 
that  the  system  be  capable  of  providing  the  functional  utility  to  meet  desired  functional 
requirements  of  the  architecture.  Even  so,  if  a  system  can  perform  other  functions  required  in  the 
architecture  in  addition  to  the  selected  functions  from  the  list  of  required  performance 
specifications,  it  will  receive  a  higher  ranking  in  the  Multi-Attribute  Analysis. 

The  third  attribute  in  the  Mulit-Attribute  Analysis  involves  determining  how  well  a  system  can 
be  integrated  or  can  interoperate  with  another  system  or  systems  to  support  the  desired  process  or 
capability.  While  acceptable  performance  in  the  first  two  attribute  areas  (the  ability  to  perform 
specific  functional  requirements  and  to  be  capable  of  supporting  multiple  functions)  is  important, 
integrated  performance  is  also  critical  to  supporting  specific  mission  capabilities.  This  part  of  the 
assessment  is  also  referred  to  as  the  static  interoperability  assessment. 

How  a  given  system  supports  a  future  vision  is  evaluated  as  the  fourth  attribute  of  this  process.  If 
two  systems  can  perform  the  desired  functions  but  only  one  of  the  two  can  meet  additional  future 
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requirements,  the  one  that  ean  meet  the  criteria  in  both  attributes  will  be  ranked  higher.  For 
example,  if  a  desired  system  can  support  Joint  and  combined  operations  in  addition  to  specific 
service  objectives,  it  would  score  higher  in  its  ranking. 

The  number  and  variety  of  operational  situations  the  system  can  support  will  be  evaluated  as  the 
fifth  attribute  in  determining  the  value  of  the  system  or  program.  For  FBE-I,  the  architecture 
framework  for  the  analysis  and  the  systems  that  supported  the  architecture  were  evaluated  in  six 
separate  operational  situations  that  allowed  for  varying  sensitivities  in  pursuing  different  target 
sets  and  performing  in  diverse  operational  environments.  These  varying  scenarios  enable 
analysts  to  determine  the  system’s  capability  to  support  multiple  operational  environments  and 
conditions.  In  evaluating  this  attribute,  systems  or  programs  that  can  support  the  architecture  in 
multiple  operational  situations  will  be  valued  and  will  be  ranked  higher  than  those  that  cannot. 

The  sixth  attribute  used  in  the  analysis  process  is  cost.  Lifecycle  costs  should  be  used  when 
comparing  systems  or  programs  that  support  the  various  functions  required  by  operators.  The 
lifecycle  costs  include  full  system  implementation,  maintenance,  and  personnel  training.  Within 
this  attribute,  the  higher-ranking  programs  or  systems  are  those  that  can  satisfy  desired  functions 
within  required  specifications  at  lower  costs  for  implementation  and  continued  support. 

In  addition  to  the  six  attributes  discussed  previously,  the  process  also  involves  consideration  of 
other  available  assessments  of  programs.  These  assessments  include  analyses  conducted  by  the 
Assistant  Secretary  of  Defense  (ASD)  for  Network  Integration  and  Interoperability  (Nil)  staff  in 
reviewing  C4I  Support  Plans  (C4ISPs)  at  the  program’s  major  acquisition  milestone  review. 
Technical  and  programmatic  issues  cited  by  ASDfNII)  should  also  be  used  in  the  assessment. 

The  Multi- Attribute  Analysis  results  presented  previously  in  Figure  5-12  summarized  the 
preliminary  assessment  of  the  six  attributes  for  the  primary  C2  systems  for  the  POM  04  TST 
Mission  Capability  Package.  An  analysis  of  some  of  the  information  in  that  graphic  can  provide 
a  better  understanding  of  how  Multi-Attribute  Analysis  can  be  used  to  support  acquisition 
decision-making.  In  the  graphic.  System  Numbers  5  and  6  were  targeting  systems.  One  was  an 
experimental  system,  and  the  other  was  a  legacy  Joint  system.  There  was  interest  in  the  legacy 
Joint  system  primary  because  it  was  used  by  the  Marines,  and  the  Navy  was  considering 
purchasing  it.  Using  the  Multi-Attribute  Analysis  results,  it  appears  that  purchasing  the  legacy 
system  would  not  be  a  good  idea  for  the  Navy.  The  analysis  shows  that  the  functionality  can  be 
obtained  from  other  systems,  and  it  may  present  serious  problems  in  terms  of  integration.  The 
Navy  will  need  to  interoperate  with  the  Joint  system,  but  this  interoperability  could  be 
accomplished  using  System  Number  3  (a  Navy  system  more  suitable  for  shipboard  use).  The 
Multi-Attribute  Analysis  also  addressed  the  experimental  system,  which  was  interesting  to  the 
Navy  because  it  provided  the  ability  to  support  dynamic  targeting  and  four-dimensional 
deconfliction.  Again,  the  Multi-Attribute  Analysis  indicated  that  the  system  was  not  a  good 
acquisition  choice  for  the  Navy  because  it  required  the  Navy  to  purchase  duplicative 
functionality  in  other  areas  in  order  to  get  the  one  unique  function.  Integrating  the  unique 
functionality  of  the  experimental  system  into  another  system,  like  System  2,  should  be  cheaper 
and  less  problematic. 
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Capabilities-Based  Acquisition  Planning  Using  Architecture  Framework  Products 

A  capabilities-based  acquisition  plan  aligns  the  evolution  of  systems,  technologies,  and  standards 
to  allow  development  of  a  roadmap  to  support  the  evolving  capabilities  needed  from  the  FoS. 
Three  existing  Architecture  Framework  products  and  a  proposed  new  product  can  be  used 
together  to  provide  a  description  of  the  evolution  and  acquisition  of  the  system  improvements  to 
the  FoS  that  is  traceable  to  mission  capabilities.  Describing  the  acquisition  plan  requires  three 
existing  Architecture  Framework  products  and  a  proposed  new  product: 

■  SV-9:  System  Technology  Forecast 

■  TV-2:  Standards  Technology  Forecast 

■  SV-8:  System  Evolution  Description 

■  CV-6:  Capability  Evolution  Description 

Each  of  these  products  is  described  in  the  following  paragraphs. 

System  Technology  Forecast  (SV-9) 

A  System  Technology  Forecast  (SV-9)  is  a  detailed  description  of  emerging  technologies  and 
specific  hardware  and  software  products.  It  contains  predictions  about  the  availability  of 
emerging  capabilities  and  about  industry  trends  in  specific  timeframes  (e.g.,  6-month,  12-month, 
18-month  intervals)  and  confidence  factors  for  the  predictions.  The  forecast  includes  potential 
technology  impacts  on  current  architectures  and  thus  influences  the  development  of  transition 
and  objective  architectures.  The  forecast  should  be  tailored  to  focus  on  technology  areas  that  are 
related  to  the  purpose  for  which  a  given  architecture  is  being  built  and  should  identify  issues  that 
will  affect  the  architecture. 

Standards  Technology  Forecast  (TV-2) 

A  Standards  Technology  Forecast  (TV-2)  is  a  detailed  description  of  emerging  technology 
standards  relevant  to  the  systems  and  business  processes  covered  by  the  architecture.  It  contains 
predictions  about  the  availability  of  emerging  standards  and  the  likely  obsolescence  of  existing 
standards  in  specific  timeframes  (e.g.,  6-month,  12-month,  18-month  intervals)  and  confidence 
factors  for  the  predictions.  It  also  contains  matching  predictions  for  market  acceptance  of  each 
standard  and  an  overall  risk  assessment  associated  with  using  the  standard.  The  forecast  includes 
potential  standards  impacts  on  current  architectures  and  thus  influences  the  development  of 
transition  and  objective  architectures.  The  forecast  should  be  tailored  to  focus  on  technology 
areas  that  are  related  to  the  purpose  for  which  a  given  architecture  description  is  being  built  and 
should  identify  issues  that  will  affect  the  architecture. 

System  Evolution  Description  (SV-8) 

The  System  Evolution  Description  (SV-8)  describes  plans  for  “modernizing”  a  system  or  suite  of 
systems  over  time.  Such  efforts  typically  involve  the  characteristics  of  evolution  (spreading  in 
scope  while  increasing  functionality  and  flexibility)  or  migration  (incrementally  creating  a  more 
streamlined,  efficient,  smaller,  and  cheaper  suite),  and  will  often  combine  the  two  thrusts.  This 
product  builds  on  the  previous  diagrams  and  analyses  in  that  information  requirements, 
performance  parameters,  and  technology  forecasts  must  be  accommodated.  In  FoS  systems 
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engineering,  the  Systems  Evolution  Deseription  will  draw  heavily  not  only  from  the  System 
Technology  Forecast  (SV-9)  but  also  the  Standards  Technology  Forecast  (TV-2).  This  is  because 
the  FoS  derives  its  capabilities  through  the  interoperation  of  systems,  not  just  through  the 
operation  of  individual  systems.  Thus,  the  evolution  of  system  connectivity  must  be  given  equal 
attention  with  individual  system  evolution. 

Capability  Evolution  Description  (CV-6) 

The  Capability  Evolution  Description  (CV-6)  is  a  proposed  new  view  under  consideration  by 
various  elements  of  the  DoD.  This  view  would  provide  a  high-level  graphic  for  managers  and 
executives  to  use  for  oversight  of  FoS  alignment  during  acquisition.  Portfolios  of  programs 
would  be  bundled  by  the  capability  increments  referred  to  in  the  Operational  Concept  (OV-1). 
Increments  of  capability  introduced  over  time  would  then  establish  the  evolution  of  the  FoS  in 
acquisition.  The  delivery  of  systems  and  the  associated  integration  and  interoperability  strategy 
would  be  aligned  and  displayed  in  the  CV-6  graphic,  so  that  cormectivity,  alignment,  and 
traceability  to  capabilities  are  all  displayed  in  one  graphic. 

FBE-I  Capability  Evolution  Description  (CV-6) 

For  FBE-I,  once  final  rankings  were  made  for  the  systems,  the  systems  ranking  the  highest  were 
mapped  into  an  acquisition  investment  strategy  over  time  to  evaluate  program  phasing.  When  the 
funding  and  schedule  data  were  plotted  over  time,  it  was  easy  to  visualize  program  dependencies 
and  phasing  issues.  The  exhibit  used  to  support  this  visualization  was  the  CED  (CV-6).  The  CED 
enabled  visualization  of  program  funding  and  schedule  data  in  a  marmer  that  provided  facilitated 
identification  of  program  dependencies  and  phasing  for  specific  capability  objectives  desired  by 
a  designated  year.  Figure  5-13  provides  an  illustration  of  the  CED.  As  shown  in  Figure  5-13, 
programs  of  record  can  be  aligned  to  specific  desired  capability  objectives  over  time  using  a 
CED  view.  The  red,  yellow,  and  green  colors  in  the  capability  objective  lines  indicate  when  the 
specific  criteria  for  the  capability  objective  has  been  entirely  met  (green),  partially  met  (yellow), 
or  not  met  (red).  A  new  program  coming  on  line  can  cause  improvement  in  the  achievement  of  a 
capability  objective,  but  it  is  not  necessarily  the  only  cause,  nor  is  technical  achievement  of  a 
new  capability  enough  by  itself  to  ensure  achievement  of  a  capability  objective.  The  new 
program  must  also  be  funded  adequately  to  meet  IOC  by  the  objective  year,  and  it  must  be  able 
to  be  properly  integrated  with  the  other  systems  required  to  meet  the  capability  objective.  In 
other  words,  the  investment  strategy  will  result  in  meeting  the  capability  objective  only  if  the 
systems  are  developed  and  fielded  on  schedule,  have  the  proper  funding,  and  can  meet  the 
performance  criteria  in  an  integrated  fashion  as  an  FoS.  If  all  the  pieces  come  together  at  the 
right  time  and  level  of  performance,  then  the  FoS  satisfies  the  capability  objective  and  achieves 
“green”  status. 
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Figure  5-13.  CED  for  FBE-I 

The  aetual  CED  is  a  database  that  stores  the  data  to  drive  the  visualization  depicted  in  Figure  5-13. 
The  database  stores  the  systems  of  systems  data  in  groups  labeled  as  use  cases.  Each  use  case 
includes  stored  has  performance  results  associated  with  the  set  of  systems  depicted  in  a  systems 
interface  mapping  (SV-1)  linked  to  a  capability  objective.  Also  linked  to  the  capability  objective 
is  a  description  of  the  activity  flow  diagram  mapped  to  systems  functions  and  systems  (an  OV-6c 
modified).  Additionally,  programmatic  data,  including  cost  and  schedule,  is  linked  to  each 
program  listed  in  the  FoS. 

FBE-I  Results  Impact  on  Capabilities-Based  Acquisition  Planning 

The  architecture  analysis  methodology,  multi-attribute  analysis,  and  CED  used  during  FBE-I 
proved  to  be  effective  tools  for  supporting  investigation  of  major  POM-04  investments  in  the 
area  of  TST.  Specifically,  the  architecture  analysis  performed  during  FBE-I  yielded  the 
following  results: 

•  A  demonstrated  ability  to  document  FBE-I  TST  operational,  system,  and  technical 
architecture  views  that  could  then  be  used  to  define  the  TST  Mission  Capability  Package 
Architecture  in  a  standardized  DoD  format  that  could  be  compared  to  Joint  and  Combatant 
Commander  architectures 

•  The  capability  to  use  FBE-I  architecture  products  to  identify  and  evaluate  key  performance 
system  integration  and  interoperability  solutions  for  TST,  resulting  in  seven  investment 
recommendations  to  improve  TST 

•  The  demonstrated  ability  to  combine  FBE-I  architecture  products  with  Naval  Afloat 
Targeting  Integrated  Program  Team  (IPT),  Naval  Targeting  Operational  Architecture 
(NTOA),  and  National  Reconnaissance  Office  Targeting,  Processing,  Exploitation,  and 
Dissemination  (NRO  TPED)  architecture  products  to  support  POM-04  investment  decisions 
made  in  TST 
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Further,  the  FBE-I  products  and  process  provided  the  foundation  to  institutionalize  the  ASN 
RDA  (CHENG)  architectural  analysis  approach  for  future  assessments  of  the  Navy  POM. 
Following  FBE-I,  the  ASN  RDA  CHENG  and  the  Commander  of  NWDC  signed  a 
Memorandum  of  Agreement  under  which  ASN  RDA  CHENG  agreed  to  provide  future 
experiment  support  through  architecture  analysis  and  to  use  the  results  of  these  analyses  to 
support  investment  decisions  in  a  number  of  warfare  areas.  The  architecture  analysis  process 
used  during  FBE-I  and  described  in  this  chapter  will  be  employed  during  future  FBEs  to  support 
architecture  documentation  and  comparison  as  well  as  evaluation  of  system  integration  and 
interoperability.  This  process  is  summarized  in  the  following  steps: 

•  Step  1 :  Use  the  Operational  Architecture  Views  derived  from  the  FBE  concept  of  operations 
and  validated  by  the  Naval  Forces  and  Combatant  Commanders  participating  in  the 
experiment  to  identify  the  key  activities  and  capability  objectives. 

•  Step  2:  Gather  existing  systems  functions  from  the  appropriate  Systems  Commands.  Map  the 
system  functions  to  the  activities,  and  then  map  appropriate  systems  to  the  functions.  These 
mappings  will  provide  a  first  order  assessment  that  will  enable  identification  of  potential  gaps 
and  overlaps  in  systems  supporting  the  required  functions  based  on  the  desired  operational 
activities.  Use  Naval  Forces  and  Combatant  Commander  representatives  to  identify  the 
existence  of  necessary  and  unnecessary  overlaps  and  gaps. 

•  Step  3:  Identify  any  and  all  interoperability  and  integration  problems  that  are  affecting  or  will 
affect  the  achievement  of  desired  Joint  capability  objectives.  Use  existing  databases  that 
assess  standards  and  protocols  between  the  nominated  systems.  Use  documented 
interoperability  issues  recorded  in  the  C4ISP  program  database  to  identify  interoperability 
problems  that  may  exist  between  the  identified  systems. 

•  Step  4:  Use  ongoing  experimentation,  modeling  and  simulation  results,  operational  lessons 
learned,  and  executable  architecture  models  to  evaluate  the  performance  and  operational 
impact  associated  with  key  interoperability  problems. 

•  Step  5:  Document  an  acquisition  plan  to  correct  key  interoperability  and  program 
synchronization  problems  identified  in  the  assessment  process.  Use  a  CED  view  to  map  key 
system  schedule,  funding,  and  dependency  factors  to  desired  capability  objectives.  Use  an 
existing  database  approach  that  enables  storage  of  performance  data  with  operational, 
systems,  and  acquisition  views  to  facilitate  visualization  and  comprehension  of  desired 
capability  objectives  in  relation  to  specific  systems,  their  functions,  their  interfaces,  and  their 
programmatic  data,  including  cost  and  schedule. 

Figure  5-14  illustrates  the  process  used  in  FBE-I  that  will  be  applied  to  identify  and  solve  key 
interoperability  and  integration  problems  in  future  experiments. 
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Figure  5-14.  Summary  of  the  FBE-I  Architecture  Analysis  Process 


Summary 

Conducting  architecture  analysis  for  the  Joint  Fires  TST  portion  of  FBE-I  provided  valuable 
experience  in  documenting,  recording,  and  analyzing  technical  and  system  functional 
architecture  views  and  in  using  these  architecture  products  to  identify  and  evaluate  key 
performance  system  integration  solutions.  Further,  the  architecture  analysis  process  was 
institutionalized  during  the  experiment  to  enable  its  future  use  in  supporting  architecture 
documentation  and  comparison  as  well  as  evaluation  of  system  integration  and  interoperability. 
The  architecture  analysis  process  used  in  FBE-I  begins  with  developing  an  operational  concept 
to  identify  operational  activities  linked  to  achieving  desired  capability  objectives.  It  continues 
with  the  listing  of  system  functions  and  the  mapping  of  these  functions  to  activities  and  systems 
to  identify  potential  gaps  and  overlaps.  The  next  step  is  the  conduct  of  a  system  interface 
analysis  to  identify  interoperability  problems,  and  this  step  is  followed  by  a  multi-attribute 
analysis  to  determine  the  impact  of  these  interoperability  problems  on  performance  and 
operational  issues.  The  final  step  is  the  mapping  of  key  systems  to  mission  capabilities  using  a 
CED  to  facilitate  visualization  and  comprehension  of  desired  capability  objectives  in  relation  to 
specific  systems,  their  functions,  their  interfaces,  and  their  programmatic  data,  including  cost  and 
schedule.  The  use  of  this  process  during  FBE-I  proved  effective  in  supporting  acquisition 
analysis  in  the  area  of  TST  during  POM-04,  and  it  will  be  used  in  future  FBEs  to  support 
investment  decision-making  in  a  wide  variety  of  warfare  areas. 
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CHAPTER  6^ 

JOINT  MARITIME  COMMAND  AND  CONTROL  CAPABILITY 


Purpose 

This  chapter  discusses  the  Joint  Maritime  Command  and  Control  Capability  program,  which  was 
undertaken  jointly  by  Naval  Sea  Systems  Command  (NAVSEA)  and  the  Space  and  Naval 
Warfare  Systems  Command  (SPA WAR)  to  define  the  future  sea-based  command  and  control 
capability  and  to  develop  the  underlying  architecture  to  support  Joint  Command  and  Control 
from  a  sea-based  platform.  The  Joint  Maritime  Command  and  Control  Capability  (Experimental) 
(JCC(X))  architecture  incorporates  the  three  views  (Operational,  Systems,  and  Technical)  that 
have  been  described  in  detail  in  the  previous  chapters  of  this  book,  but  it  provides  specific  focus 
on  command  and  control  capability  and  offers  a  detailed  look  at  translating  operational 
requirements  into  operational  views.  This  chapter  also  provides  an  in-depth  view  of  the 
Information  Exchange  Requirements  (lERs)  associated  with  the  Operational  View  of  the 
architecture.  Despite  the  fact  that  JCC(X)  as  a  program  has  been  cancelled,  the  C4I  mission 
package  that  this  architecture  describes  lives  on.  A  command  and  control  variant  that  will  use  the 
JCC(X)  architecture  to  support  the  requirements  process  is  currently  being  explored,  and  the 
OSD  Force  Transformation  Office  has  expanded  the  JCC(X)  executable  architecture  to  support 
training  and  experimentation. 

Background 

NAVSEA  was  tasked  by  CNO  to  define  the  future  sea-based  command  and  control  capability 
associated  with  supporting  military  operations  for  a  Commander,  Joint  Task  Force  (CJTF).  The 
effort,  which  was  called  the  Joint  Maritime  Command  and  Control  Capability,  also  involved 
SPA  WAR,  which  was  tasked  with  developing  the  underlying  architecture  to  support  the  Joint 
Command  and  Control  Ship  C4ISR  requirements  in  operational  environments  and  situations. 
SPA  WAR  was  also  tasked  with  identifying  the  architecture  requirements  associated  with  the 
joint  operation  of  U.S.  forces  with  Allied  and  Coalition  partners.  Other  Government 
Organizations  (OGOs),  Non-Govemment  Organizations  (NGOs),  and  Private  Volunteer 
Organizations  (PVOs)  when  they  were  resident  on  board  the  Joint  Command  and  Control  Ship. 

At  the  time  of  the  writing  of  this  book,  the  latest  version  of  the  JCC(X)  Architecture  had  just 
been  released.  It  was  developed  as  a  blueprint  to  support  development  of  inputs  to  the  JCC(X) 
ORD  and  the  JCC(X)  C4I  Support  Plan  (C4ISP).  It  was  also  used  to  support  the  Analysis  of 
Alternatives  and  will  be  used  as  a  basis  for  the  Preliminary  Specification  (P-Spec).  Figure  6-1 
shows  the  sources  of  information  for  the  architecture  development  as  well  as  the  products  the 
architecture  was  designed  to  ultimately  support. 

The  Joint  Task  Force  (JTF)  Representative  C4ISR  Operational  Architecture  (JRCOA), 
developed  by  the  Joint  Battle  Center  for  U.S.  Joint  Forces  Command  (USJFCOM),  was  used  as 
the  baseline  for  the  development  of  the  JCC(X)  Architecture.  The  JRCOA  database  was  then 
expanded  to  meet  the  requirements  of  the  JCC(X)  by  including  elements  of  the  Joint  Force  Air 
Component  Commander  (JFACC),  Joint  Force  Maritime  Component  Commander  (JFMCC), 


^  This  description  of  the  JCC(X)  program  was  prepared  by  Dennis  Rilling  and  Kar  Chan  of  the  Space  and  Naval 
Warfare  Systems  Command  (SPAWAR)  Requirements  Analysis  and  Assessments  Department  (SPAWAR  051)  and 
Carl  Carden  et  al  with  MITRE.  The  project  was  funded  by  the  Chief  of  Naval  Operations. 
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Figure  6-1.  Sources  of  Information  for  and  Products  from  Architecture  Development 


Joint  Force  Land  Component  Commander  (JFLCC),  Joint  Psychological  Operations  Task  Force 
Commander  (JPOTFC),  Joint  Civil  Military  Operations  Task  Force  Commander  (JCMOTF), 
Joint  Forces  Special  Operations  Component  Commander  (JFSOCC),  and  Allied/Coalition  forces. 


JCC(X)  Architecture  Overview 

The  JCC(X)  Architecture  incorporates  the  three  interrelated  but  separate  views  (Operational, 
Systems,  and  Technical)  that  have  been  described  in  detail  in  the  previous  chapters  of  this  book. 
The  Operational  View  describes  the  operational  concept  the  architecture  is  being  developed  to 
support  and  identifies  process  and  information  requirements.  For  JCC(X),  the  Operational  View 
focuses  on  the  mission  requirements,  activities,  and  information  exchange  needs  of  the  CJTF, 
JFACC,  JFMCC,  JFLCC,  JPOTF,  JFSOCC,  JCMOTF,  and  Allied/Coalition  commands  and 
undefined  organizations  that  may  be  part  of  the  JCC(X)  mission.  As  described  in  the  JCC(X) 
MNS,  the  JCC(X)  mission  can  range  from  Humanitarian  Assistance/Disaster  Relief  (HA/DR)  to 
Major  Theatre  War  (MTW).  The  majority  of  this  chapter  focuses  on  the  JCC(X)  Operational 
Concept  and  the  Operational  Views  developed  to  support  that  concept. 

The  Systems  View  describes  how  the  process  and  information  requirements  identified  in  the 
Operational  Views  are  to  be  implemented.  For  JCC(X),  the  Systems  View  focuses  on 
functionality  of  system  types  rather  than  actual  systems  and  depicts  how  multiple  system  types 
link  and  integrate  based  upon  the  capabilities  and  operation  of  particular  system  types  within  the 
architecture.  The  JCC(X)  Systems  View  provides  functional  node  descriptions  to  support  the 
development  of  the  C4ISR  Mission  Package  Performance  Specifications  and  Support  Plan. 
These  functional  nodes  are  defined  as  nodes  that  support  the  operations  of  command  nodes. 
Additionally,  the  Systems  View  identifies  and  depicts  the  DoD  system  type  requirements  for 
parameters  including  security,  interoperability,  and  reach-back. 


Using  Architectures  for  Research,  Development,  and  Acquisition 


93 


The  Technical  View  identifies  the  standards  that  must  he  used  to  support  interoperahility 
interfaces.  Developing  the  Technical  Architecture  (TA)  involves  identifying  applicable  portions 
of  existing  technical  guidance  documentation,  tailoring  those  portions  as  needed  and  in 
accordance  with  the  latitude  allowed,  and  filling  in  any  gaps.  The  JCC(X)  architects  recognized 
that  the  services  and  standards  defined  in  the  Joint  Technical  Architecture  (JTA)  were  based  on 
current  technology  and  might  no  longer  be  applicable  when  JCC(X)  was  expected  to  be 
implemented  (the  2011  time  frame).  Accordingly,  the  JCC(X)  architects  chose  to  use  the  Global 
Information  Grid  (GIG)  and  its  associated  interfaces,  which  are  known  as  Key  Interface  Points 
(KIPs),  in  combination  with  the  JTA  to  develop  the  Technical  Views  for  JCC(X).  The  JTA 
services  and  standards  and  the  GIG  KIPs  were  identified  at  the  interfaces  between  all  of  the 
JCC(X)  node  pairs  depicted  in  the  System  Interface  Description  (SV-1)  developed  in  the 
Systems  View. 

JCC(X)  Operational  Concept 

To  describe  the  JCC(X)  Operational  Concept,  the  architects  developed  the  following  products: 

•  High-Level  Operational  Concept  Graphic  (OV-1) 

•  Operational  Node  Connectivity  Description  (OV-2) 

•  Command  Relationships  Chart  (OV-4) 

•  Operational  Event/Trace  Description  (OV-6c) 

•  Executable  Model 

Details  on  the  architecture  products  developed  to  support  the  JCC(X)  Operational  Concept  are 
presented  in  the  following  paragraphs. 

High-Level  Operational  Concept  Graphic  (OV-1) 

The  High-Level  Operational  Concept  Graphic  (OV-1)  depicts  the  high-level  command  nodes 
that  were  envisioned  for  JCC(X).  This  product  depicts  the  nodal  connectivity  displayed  in  the 
Operational  Node  Connectivity  Description  (OV-2)  products  presented  later  in  this  chapter.  The 
OV-1  information  presented  in  this  section  is  displayed  in  the  context  of  the  five  phases  of  JTF 
operations  in  a  generic  operational  scenario.  These  phases  (Pre-Deployment,  JTF  Afloat,  JTF 
Afloat-to-Ashore  Transition,  JTF  Ashore,  and  JTF  Shore-to-Afloat  Transition)  reflect  how 
connectivity  between  nodes  may  change  based  upon  the  operational  phase.  Figures  6-2  and  6-3 
provide  a  sample  High-Level  Operational  Concept  Graphic  for  two  of  the  five  phases,  JTF 
Afloat  and  JTF  Afloat-to-Ashore  Transition. 

Operational  Node  Connectivity  Description  (OV-2) 

Nodes  and  nodal  connectivity  (also  referred  to  as  need  lines)  of  the  Operational  View  are  shown 
graphically  in  the  Operational  Node  Connectivity  Description  (OV-2)  product.  Complete  and 
accurate  identification  of  the  need  lines  in  the  Operational  Node  Connectivity  Description 
provided  a  basis  for  ensuring  that  all  required  connectivity  was  achievable. 

It  should  also  be  noted  that  the  requirement  to  support  Allied  and  Coalition  operations  created 
unique  requirements  that  had  to  be  addressed  in  the  Operational  Node  Connectivity  Description. 
In  the  Operational  Node  Connectivity  Description  products  developed  for  JCC(X),  Allied  and 
Coalition  Forces  were  integrated  into  the  JTF/Component  Command  structure.  Also  shown  in 
the  Operational  Node  Connectivity  Description  products  were  the  information  exchanges 
between  the  component  commanders  and  the  command  level  of  the  tactical  forces. 
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Allied  and  Coalition  fSATCOIVh 


Figure  6-2.  High-Level  Operational  Coneept  Graphie  (OV-1)  for  JTF  Afloat 


JFACC  - JSOTF 

JFMCC  - JPOTF 

JFLCC  .  Connectivity  with  Theatre,  CONUS,  Civil  Affairs, 

Allied  and  Coalition  (SATCOM) 


"igure  6-3.  High-Level  Operational  Concept  Graphic  (OV-1)  for  JTF  Afloat-to-Shore  Transition 
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Figure  6-4  provides  a  JTF-centric  Operational  Node  Connectivity  Description  depicting  the 
operational  nodes  and  elements  and  the  need  lines  (information  flows)  between  them.  All  nodes 
and  organizations  that  could  have  been  located  onboard  the  Joint  Command  and  Control  Ship  are 
shown  inside  the  shaded  box.  The  red  triangle  in  the  comer  of  a  box  indicates  the  presence  of 
Allied/Coalition  personnel  within  that  nodal  command  structure.  Since  it  was  envisioned  that  the 
Service  Organizations  could  have  command  elements  located  on  the  Joint  Command  and  Control 
Ship  and  tactical  elements  located  elsewhere,  they  are  shown  partially  inside  the  shaded  box  and 
partially  outside. 


SN  —  ST  Levels  of  War  OP  Level  of  War  Tactical  Level  of  War 

National  CINC  JTF  Staff  JTF  Component  Service  Component 


"igure  6-4.  JTF-Centric  Operational  Node  Connectivity  Description  (OV-2)  for  JCC(X) 

Each  of  the  boxes  within  the  JCC(X)  shaded  area  in  Figure  6-4  can  be  decomposed  to  display  a 
view  from  the  perspective  of  that  box.  Figure  6-5  provides  another  JTF-centric  Operational  Node 
Connectivity  Description  view  decomposed  down  to  its  sub-elements  (e.g.,  Jl,  J2,  J3,  etc.). 

Similar  views  for  each  of  the  major  Component  Commanders  (JFACC,  JFLCC,  JFMCC,  JSOTF) 
were  developed  as  an  expansion  of  the  work  done  in  the  JFCOM  JRCOA.  Additional  views  were 
developed  to  reflect  the  perspective  of  the  JPOTFC  and  the  JCMOTF.  Operational  Node 
Connectivity  Description  products  for  JPOTF  and  JCMOTF  centric  views  are  provided  in  Figure 
6-6  and  6-7. 
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Figure  6-5.  JTF-Centric  Operational  Node  Connectivity  Description  (OV-2)  Decomposed  to 
Sub-Element  Views 


Figure  6-6.  JPOTF-Centric  Operational  Node  Connectivity  Description  (OV-2)  for  JCC(X) 
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Command  Relationships  Chart  (OV-4) 

The  anticipated  High-Level  Command  Relationships  that  were  anticipated  to  support  the  JCC(X) 
are  presented  in  the  Command  Relationships  Chart  (OV-4)  in  Figure  6-8.  As  shown,  the  CJTF 
had  overall  responsibility  for  the  Service  Components  (shown  in  the  second  tier  of  the  chart)  as 
well  as  the  JFACC,  JFLCC,  JFMCC,  JFSOCC,  JCMOTF,  and  JPOTF. 


Figure  6-8.  High-Level  Command  Relationships  Chart  (OV-4)  for  JCC(X) 
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A  decomposition  of  each  of  the  high-level  commands  and  a  discussion  of  the  responsibilities  of 
each  of  the  sub-elements  were  also  developed  in  the  JCC(X)  architecture.  Figure  6-9  reflects  the 
JTF  decomposition  and  functional  boards  and  groups  within  the  JTF.  Each  of  the  major 
organizations  was  then  further  decomposed  to  the  next  level  of  detail.  Figure  6-10  shows  this 
level  of  decomposition  for  the  JTF  J3  organization. 
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Figure  6-9.  Notional  JTF  Headquarters  Command  Relationships  Chart  (OV-4) 
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Figure  6-10.  Notional  JTF  J-3  Command  Relationships  Chart  (OV-4) 

Operational  Event/Trace  Description  (OV-6c) 

Most  of  the  Operational  View  products,  including  the  High-Level  Operational  Concept  Graphic 
(OV-1),  the  Operational  Node  Connectivity  Description  (OV-2),  the  Operational  Information 
Exchange  Matrix  (OV-3),  the  Command  Relationships  Chart  (OV-4),  and  the  Activity  Model 
(OV-5),  provide  static  views  of  the  architecture.  While  these  products  are  helpful  in  building  the 
Operational  View,  it  is  important  to  note  that  many  of  the  critical  characteristics  of  an 
architecture  can  only  be  discovered  when  an  architecture's  dynamic  behavior  is  defined  and 
described.  This  dynamic  behavior  includes  the  timing  and  sequencing  of  events  that  frame  the 
operational  behavior  of  a  process.  The  Operational  Event/Trace  Description  (OV-6c)  describes 
critical  timing  and  sequencing  behavior  in  the  Operational  View,  and  it  is  the  first  of  the 
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Operational  View  produets  that  provides  a  dynamic  view  into  the  architecture.  Both  static  and 
dynamic  views  provide  benefits  in  developing  the  architecture.  Figure  6-11  highlights  some  of 
these  benefits. 


Visualization 


Architectures:  How  do  they  fit? 
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identifying,  resolving  definitions,  properties, 
facts,  constraints,  inferences,  and  issues  both 
within  and  across  models  that  are  redundant, 
conflicting,  missing,  and/or  obsolete 


*  Identify  and  convert  inconsistent  “dirty” 
architecture  data,  where  different  names 
mean  the  same  thing  (synonyms)  or  where 
the  same  name  means  different  things 
(homonyms)  into  consistent  “clean” 
architecture  data 

*  Mine  architecture  data  to  discover  hidden 
enterprise  rules,  practices,  relationships, 
requirements,  behavior  and  patterns  about 
how  enterprise  conducts  its  business 

*  Determine  effect  and  impact  of  change 
(“what  if’)  when  something  is  redefined, 
redeployed,  deleted,  moved,  delayed, 
accelerated,  de funded 


Dynamic  (OV-6, 
SV-10) 


Executable 

Architecture 


*  Enabled  complex  operational 
processes,  their  resources, 
costs,  manpower,  and  the 
relationships  between  them  to 
be  understood,  simplified, 
measured  and  optimized  for 
efficiency,  effectiveness,  and 
performance 

*  Validate  and  verify  original 
enterprise’s  operational 
architectural  assumptions 

*  Measure  process,  system 
performance,  individual 
person/  organizational  work 
efforts  and  equipment 
resource  utilization  over  time 


Figure  6-11.  Benefits  of  Static  and  Dynamic  Views  in  the  Architecture 


Dynamic  views  support  the  development  of  executable  architectures  that  are  designed  to  enable 

architects  to  perform  the  following  tasks: 

•  Identify  Key  Performance  Parameters  (KPPs)  associated  with  Mission  Essential  Tasks  and 
Threads 

•  Facilitate  analysis  in  split-base  organization  and  staffing,  organizational  consolidation,  and 
split-base  communication  requirements 

•  Develop  and  analyze  of  system  design  requirements 

In  developing  and  implementing  an  executable  model  for  the  JCC(X),  system  architects 

employed  the  following  process: 

•  Identification  of  what  to  model  using  approved  Joint  Mission  Essential  Task  Lists  (JMETLs) 
as  the  source  and  correlating  source  data  to  Joint  Chiefs  of  Staff  (JCS)  Mission  Areas 

•  Development  of  the  model  through  utilization  and  reuse  of  existing  information  and 
refinement  of  information  by  Subject  Matter  Experts 

•  Execution  of  the  model  and  performance  of  mission-specific  needs  assessment  involving 
trade-off  analysis  balancing  doctrine  and  Tactics,  Techniques,  and  Procedures  (TTPs), 
manning  and  organization,  and  system  requirements 

Figure  6-12  provides  a  graphical  depiction  of  this  process. 
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To  develop  the  model,  it  was  necessary  to  recognize  a  natural  order  among  the  1 1  Joint  Mission 
Areas  (JMAs).  Figure  6-13  shows  this  natural  ordering. 
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Figure  6-14  provides  a  high-level  view  of  the  completed  model  that  illustrates  the  complexity  of 
operations  at  the  Joint  Task  Force  Headquarters.  Each  of  the  yellow  boxes  in  the  graphic 
correlates  with  the  11  JMAs  shown  in  Figure  6-13,  and  each  has  its  own  set  of  sequenced 
activities,  information  exchanges,  organizations,  and  system  resources  used  to  support  these  activities. 


A  clearer  view  of  the  thread  analysis  and  the  Measures  of  Effectiveness  (MOEs)  and  Measures 
of  Performance  (MOPs)  associated  with  each  thread  is  provided  in  Figure  6-15.  By  providing  the 
architect  with  the  ability  to  fully  execute  each  of  these  threads,  the  executable  model  delivers 
significant  power  in  supporting  analysis  of  business  processes,  organizational  structure,  and 
system  performance  and  helps  determine  the  best  methods  for  achieving  improvements. 


Figure  6-15.  Critical  Thread  Analysis  and  Associated  MOEs  and  MOPs 
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The  Joint  Air  Tasking  Order  Process/Time  Critical  Evaluation  was  one  thread  in  the  JCC(X) 
process  for  which  an  Operational  Event/Trace  Description  (OV-6c)  and  executable  model  were 
developed.  Figures  6-16  though  6-22  show  how  each  activity  in  this  thread  was  identified  and 
then  decomposed  into  further  levels  of  detail  in  order  to  support  the  development  of  the 
executable  model.  The  graphics  begin  with  the  Operational  Event/Trace  Description  for  the  high- 
level  air  campaign  process  and  continue  with  a  decomposition  of  the  high-level  “Generate  ATO” 
process.  The  subsequent  figures  show  the  decomposition  of  activities  including  Perform 
Targeting,  Weaponeering,  ATO  Mission  Area  Analysis  Planning  (MAAP)  Generation,  ATO  Air 
Control  Order  Generation,  and  Final  ATO  Generation. 
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Figure  6-16.  Operational  Event/Trace  Description  (OV-6c)  for  High-Level  Air  Campaign 
Process 
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Figure  6-17.  Operational  Event/Trace  Description  (OV-6c)  for  High-Level  Generate  ATO 
Process 
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"igure  6-18.  Operational  Event/Trace  Description  (OV-6c)  for  ATO  Development  Phase 


Using  Architectures  for  Research,  Development,  and  Acquisition 


106 


m 

Input 

5 

Perform  Targeteering 


m 

Input 

13 

Perform  Targeteering 


\ 

JIPTL, 
Hard  Copy 

1 

L 

sends  Final 
Apportionment 
Plan 


x; 


Develop 

^  === 

Target 

13 

DMPIs 

— - - 1  uses  |- - 

Rapid 

Weapons 

Application  of 

Planners 

Air  Power 

sends 

DMPIs 


1 


Create 

U 

Target 

Planning 

Worksheets 

For  Each 

Target 

Weapons 

Planners 

S|=== 

Images 

Check 

Feasabilitv  of 

15 

hitting  target 

sends  Target 
Planning 
Worksheets 
with  Hard 
Copy 


Output 

5 

Generate  MAAP 


Figure  6-19.  Operational  Event/Trace  Description  (OV-6c)  for  ATO  Weaponeering  Phase 
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the  organization  performing  that  activity.  The  white  boxes  depict  the  information  being  transferred. 


Figure  6-20.  Operational  Event/Traee  Deseription  (OV-6e)  for  ATO  MAAP  Generation 
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Figure  6-21.  Operational  Event/Trace  Description  (OV-6c)  for  ATO  Air  Control  Order 
Generation 
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Figure  6-22.  Operational  Event/Trace  Description  (OV-6c)  for  Final  ATO  Generation 
Operational  Views  and  Executable  Architectures 

As  shown  in  the  detailed  graphics  provided  in  this  section,  the  Operational  Views,  and 
particularly  the  OV-6c  products,  are  critical  to  the  development  of  executable  architectures. 
These  executable  models  are  incredibly  valuable  tools  in  enabling  visualization  of  complex 
processes  and  in  supporting  development  of  MOEs  and  MOPs  that  can  be  used  in  a  variety  of 
ways  to  support  trade  off  studies  and  analysis.  Specifically,  executable  architectures  can  be  used 
to  support  doctrine  and  TTP  evolution;  process  analysis  and  reengineering;  identification  of  IT 
support  redundancies,  shortfalls,  and  integration  opportunities;  staffing  analysis;  split-base 


Using  Architectures  for  Research,  Development,  and  Acquisition 


110 


analysis;  Network  Centric  Operations;  theater  bandwidth/resource  allocations;  training,  exercise, 
and  experimentation  development;  and  POM  development. 

JCC(X)  Systems  View 

The  Systems  View  describes  how  the  process  and  information  capabilities  identified  in  the 
Operational  View  are  to  be  implemented.  The  JCC(X)  Systems  View  provided  functional  node 
descriptions  to  support  the  development  of  the  JCC(X)  C4ISP  and  the  JCC(X)  Joint  Mission 
Package  Performance  Specifications.  Additionally,  the  JCC(X)  Systems  View  identified  and 
depicted  the  DoD  system-type  requirements  to  support  security,  interoperability,  and  reach-back 
needs.  Since  the  actual  systems  that  would  be  in  use  at  the  time  (the  year  2011)  when  JCC(X) 
was  expected  to  be  fielded  could  not  be  defined,  the  term  “System  Type”  was  used  in  place  of 
the  actual  names  of  systems.  System  Types  were  used  as  generic  descriptors  of  system 
functionality  that  enabled  architects  to  avoid  presupposing  that  a  specific  system  known  today 
would  be  used  on  the  JCC(X).  The  architects  did  assume  that  the  Global  Information  Grid  (GIG) 
or  a  similar  system  would  provide  the  infrastructure  necessary  to  support  the  connectivity 
required  by  the  JCC(X).  Accordingly,  the  architects  developed  the  Systems  View  within  the  GIG 
context.  A  System  Interface  Description  (SV-1)  for  JCC(X)  is  provided  in  Figure  6-23. 


JCC(X)  Technical  View 

The  Technical  View  identifies  the  standards  or  “building  code”  to  be  used  in  development.  A 
major  element  of  the  Technical  View  is  the  Technical  Architecture  Profile  (TV-1),  which 
references  the  technical  standards  that  apply  to  the  architecture  and  how  they  need  to  be  or  have 
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been  implemented.  The  C4ISR  Arehitecture  Framework,  Version  2.0,  requires  the  Technieal 
View  to  contain  a  matrix  of  specific  services  and  standards,  and  Interim  Regulation  DoD  5000.2- 
R  (Section  2.7.2. 1)  states  that  the  JTA  will  serve  as  the  foundation  for  the  development  of  the 
mission  architecture  (i.e.,  the  Technical  View).  The  JCC(X)  architects  understood  the 
requirement  to  develop  the  JCC(X)  Technical  View  and  identified  the  standards  required  to 
support  the  interoperability  interfaces  for  JCC(X),  but  they  also  recognized  that  the  JTA  services 
and  standards  were  based  on  today's  technology  and  might  not  apply  to  the  JCC(X)  since  it  was 
not  expected  to  be  delivered  until  the  201 1  time  frame.  Accordingly,  the  JCC(X)  architects  chose 
to  use  the  GIG  and  its  associated  interfaces,  which  are  known  as  KIPs,  in  combination  with  the 
JTA  to  develop  the  Technical  Views  for  JCC(X).  The  JTA  services  and  standards  and  the  GIG 
KIPs  were  identified  at  the  interfaces  between  all  of  the  JCC(X)  node  pairs  depicted  in  the 
System  Interface  Description  (SV-1)  developed  in  the  Systems  View.  Table  6-1  provides  a 
representative  Technical  Architecture  Profile  (TV-1)  highlighting  the  use  of  both  the  GIG  and 
JTA  in  developing  the  Technical  View. 


Table  6-1 


JCC(X)  Representative  Technical  Architecture  Profile  (TV-1)  for  External  Links 


From  JCC(X) 
to/from 

JTA  Service  View 

GIG  KIP  View  as 
JCC(X)  Technical  View 

JTA  Services 

GIG  KIPS 

AFFOR 

1,  2,  3(all),  4,  6,  8,  9,  10(A,B),  12(D,E),  13,  14 

1,2,  8,  10,  11 

ARFOR 

1,  2,  3(all),  4,  6,  8,  9,  10(A,B),  12(D,E),  13,  14 

1,2,  8,  10,  11 

NAVFOR 

1,  2,  3(all),  4,  6,  8,  9,  10(A,B),  12(D,E),  13,  14 

1,2,  8,  10,  11 

MARFOR 

1,  2,  3(all),  4,  6,  8,  9,  10(A,B),  12(D,E),  13,  14 

1,2,  8,  10,  11 

NIMA 

1,  2,  3(A,C,D,E),  6,  8,  9,  10(A,B),  12(D,E),  13,  14 

2,  4,  8,  10,  11 

CINC 

1,  2,  3(all),  4,  6,  8,  9,  10(A,B),  12(D,E),  13,  14 

2,  4,  8,  10,  11 

NSA 

1,  2,  3(A),  6,  8,  9,  10(A,B),  12(D,E),  13,  14 

2,  4,  8,  10,  11 

TRANSCOM 

1,  2,  3(A),  6,  8,  9,  10(A,B),  12(D,E),  13,  14 

2,  4,  8,  10,  11 

DIA 

1,  2,  3(A,D,E),  6,  8,  9,  10(A,B),  12(D,E),  13,  14 

2,  4,  8,  10,  11 

NMCC 

1,  2,  3(A),  6,  8,  9,  10(A,B),  12(D,E),  13,  14 

2,  4,  8,  10,  11 

CGFOR 

1,  2,  3(A),  6,  8,  9,  10(A,B),  12(D,E),  13,  14 

2,  4,  8,  10,  11 

State  Dept. 

1,  2,  3(A),  6,  8,  9,  10(A,B),  12(D,E),  13,  14 

2,  4,  8,  10,  11 

Summary 

JCC(X)  as  a  program  has  been  cancelled,  but  the  C4I  mission  package  that  this  architecture 
describes  lives  on.  A  command  and  control  variant  that  will  use  the  JCC(X)  architecture  to 
support  the  requirements  process  is  currently  being  explored,  and  the  OSD  Force  Transformation 
Office  has  expanded  the  JCC(X)  executable  architecture  to  support  training  and  experimentation. 
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CHAPTER  7 

A  COALITION  INTEGRATED  AIR  PICTURE 


Purpose 

The  first  four  case  studies  in  this  part  of  the  book  demonstrated  the  use  of  the  architecture 
products  to  support  different  purposes,  including  analysis  of  the  ability  of  an  FoS  to  deliver 
specific  mission  capabilities,  assessment  of  alternative  systems  in  building  an  acquisition  plan, 
and  development  of  architectures  to  support  design  of  completely  new  FoSs.  The  final  case 
study,  a  Coalition  Integrated  Air  Picture  (CIAP),  demonstrates  how  a  capability  such  as  an 
integrated  air  picture  for  coalition  partners  can  be  used  as  an  operational  node  within  a  mission 
warfare  architecture.  It  focuses  on  the  use  of  architecture  products,  including  executable 
architectures,  in  describing  performance  and  behavior.  The  results  presented  in  this  chapter  were 
a  tundamental  in  influencing  Coalition  partner  decisions  regarding  how  to  proceed  with  the 
CIAP. 

Background 

The  concept  of  a  CIAP  means  different  things  to  different  organizations.  To  some,  it  may  imply 
a  centralized  location  where  data  from  all  participating  platforms  is  displayed  to  provide 
situational  awareness;  to  others,  it  may  imply  a  distributed  network  where  all  providers  of  data 
also  receive  all  data  of  fire  control  quality;  to  still  others,  it  would  imply  something  completely 
different.  When  working  across  organizational  and  political  boundaries,  the  probability  that  each 
user  will  have  a  different  understanding  of  CIAP  concepts  is  great.  These  differences  in 
conceptual  understanding  lead  to  differences  in  methods  of  implementation.  In  other  words,  it  is 
simple  for  organizations  to  agree  that  sharing  air  track  data  would  be  beneficial,  but  it  requires 
significantly  more  thought  on  the  part  of  these  organizations  to  determine  and  agree  upon  how 
this  sharing  should  be  implemented. 

The  Coalition  Partners  (Australia,  Canada,  New  Zealand,  the  United  Kingdom,  and  the  United 
States)  all  provide  representation  to  The  Technical  Cooperation  Program  (TTCP)  for  English 
speaking  countries.  The  TTCP’s  Technical  Panel  Four  (TP-4),  in  recognition  of  the  multi-faceted 
task  at  hand,  decided  to  document  a  CIAP  operational  concept  and  its  implementation  through 
the  use  of  architectures.  The  CIAP  architecture  will  provide  traceability  from  the  CIAP 
requirements  to  the  CIAP  operational  concept  and  then  to  physical  implementation.  The 
Coalition  Partners  have  chosen  the  U.S.  DoD  C4ISR  Architecture  Framework  as  the  architecture 
standard  for  performing  this  documentation  task.  The  use  of  architectures  and  specifically  the 
C4ISR  Architecture  Framework  will  give  structure  to  the  definition  and  physical  implementation 
of  the  CIAP  concept. 

For  a  geographically  distributed  effort  such  as  a  CIAP,  it  is  possible  to  achieve  marked 
acceleration  in  the  development  process  by  working  within  an  established  process  via  a  24-hour 
accessible  collaborative  engineering  environment^"^  to  physically  instantiate  the  CIAP  concept. 
Semi-annual  meetings  among  the  TP -4  national  partners  are  augmenting  this  collaborative 
environment. 
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CIAP  Operational  Concept 

To  describe  the  CIAP  Operational  Concept,  an  Operational  View  and  an  Activity  Model  are 
being  developed.  Details  on  the  architecture  products  being  developed  to  support  the  CIAP 
Operational  Concept  are  presented  in  the  following  paragraphs. 


CIAP  High-Level  Operational  Concept  (OV-1) 


The  architecting  process  begins  with  requirements.  The  Coalition  currently  has  a  draft  set  of 
Capstone  Requirements  that  are  undergoing  review.^^  From  these  underlying  requirements,  an 
operational  concept  can  be  depicted.  The  operational  concept  is  graphical  in  nature  but  should  be 
supplemented  by  text  describing  the  operational  concept  in  high-level  language.  The  CIAP 
Operational  Concept  is  depicted  in  Figure  7-1. 


Figure  7-1.  CIAP  High-Level  Operational  Concept  (OV-1) 


Activity  Model 

From  the  operational  concept,  the  activities  required  to  enable  the  concept  can  be  derived.  These 
activities  are  presented  in  Figure  7-2  within  the  context  of  Theater  and  Air  Missile  Defense 
operations.  The  activities  are  combinations  of  operator  actions,  supporting  system  ftmctions,  and 
automated  system  functions.  For  example,  an  operator  action  is  to  “Prepare  Courses  of  Action” 
(see  A3.1  from  Figure  7-2).  A  system  may  support  the  operator  by  presenting  alternative  courses 
of  action.  If  alternatively,  the  course  of  action  was  chosen  by  the  system  and  acted  upon  without 
operator  intervention,  then  that  activity  would  be  frilly  automated.  From  the  Activity  Model,  the 
logical  relationships  between  activities  can  be  derived.  Figure  7-3  shows  the  logical  relations 
within  the  Theater  Air  Defense  Activity  Model. 


Using  Architectures  for  Research,  Development,  and  Acquisition 


115 


CO 

.o 


o 

CO 


CD 

CO 

c 

.o 

'is 

o 

I 

CL 

s 

O 

o 


Figure  7-2.  U.S.  Navy  TAMD  Operational  Aetivity  Model  (OV-5)  with  CIAP  Deeomposition 
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Resources 

•  Platforms 

•  Sensors 

•  Networks 


I 


Coalition 

Command 

Authority 


Monitor 


Assess 


Sustain 


Plan 


Battlespace 


Provide  Theater 
Air  Defense 


i. - - 


Execute 


Tgure  7-3.  Logical  Relations  of  the  Theater  Air  Defense  Activity  Model 


CIAP  System  Functional  Mapping 

Proposed  CIAP  system  functions  are  shown  in  italics  in  Table  7-1,  Theater  Air  Defense  System 
Function  List  (SV-4),  and  are  shown  in  purple  in  Figure  7-4,  Theater  Air  Defense  System 
Functional  View  with  CIAP  Decomposition  (SV-4).  Their  supporting  relationships  to  the  CIAP 
activities  are  shown  in  Table  7-2,  CIAP  Function  Traceability  to  CIAP  Operational  Activities 
(SV-5). 


Table  7-1* 

Theater  Air  Defense  System  Function  List  (SV-4) 


First-Level 

Functions 

Second-Level 

Functions 

Third-Level 

Functions 

Fourth-/Fifth-LeveI 

Functions 

Sense 

Single  Sensor 

Sense 

Search 

Underwater  active 

Underwater  passive 

Surf/ground  active 

Surf/ground  passive 

Horizon  air  active 

Horizon  air  passive 

Above  horizon  air  passive 

Above  horizon  air  active 

Over  the  horizon  passive 

Over  the  horizon  active 

Track 

- 

Feature  Extraction 

- 

Identification 

- 
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Sense 

Data  Fusion 

Multi-sensor  data  alignment 

Temporal  data  alignment 

Spatial  data  alignment 

Multi-sensor  data  association 

- 

Common  track  file  generation 

Update  existing  tracks 

Initiate  new  tracks 

Track  file  cutting 

Common  identification 

- 

Command 

Situational 

Assessment 

Tactical  picture  generation 

Develop  tactical  picture 

-  Update  tracks 

-  Update  intel 

-  Update  topo.  data 

-  Update  env.  data 

-  Update  ops.  data 

Display  tactical  picture 

-  Display  tracks 

-  Display  intel 

-  Display  topo.  data 

-  Display  env.  data 

-  Display  ops.  data 

-  Display  CLAP  coverage 

Battle  damage  assessment 

- 

Engagement  status  tracking 

- 

Alert  generation 

- 

Plan 

Force  planning 

Operations  planning 

Plan  CIAP 

-  ID  sensor  resources 

-  Determine  sensor 
location,  sector 
responsibility 

Mission  planning 

- 

Mission  modeling/simulation 

Model  CIAP  coverage 

-  Generate  CIAP 
employment  recs. 

-  Generate  CIAP 
contingency  coverage 

Environmental  prediction 

- 

Decision 

Target  prioritization 

- 

Target  weapons  planning 

- 

Dynamic  deconfliction 

- 

Act 

Engagement 

Execution 

Weapon  initialization/launch 

- 

Fire  control 

- 

Illumination 

- 

Intercept 

- 

Battle  damage  indication 

- 

Electronic  attack 

- 
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Act 

Force  Positioning 

Platform  transport 

- 

System  transport 

- 

Troops/cargo  transport 

- 

Interoperate 

Communicate 

Sense  Data 

CSD  services 

- 

CSD  networking 

- 

CSD  communications 

- 

Communication 
Force  Orders 

CFO  services 

- 

CFO  networking 

- 

CFO  communications 

- 

Communicate 

Status 

CS  services 

- 

CS  networking 

- 

CS  communications 

- 

Communicate 

Order 

CO  services 

- 

CO  networking 

- 

CO  communications 

- 

Precision 

Gen.  &  comm,  time 

Navigation  &  Time 

Gen.  &  comm.  nav.  data 

Generation 

Gen.  &  comm.  METOC  data 

*Note:  CIAP  functions  are  shown  in  italics. 


Note:  CIAP  functions  are  shown  in  the  purple  shaded  box  and  in  the  purple  text. 


Figure  7-4.  Theater  Air  Defense  System  Functional  View  with  CIAP  Decomposition  (SV-4) 
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Table  7-2* 

CIAP  Function  Traceability  to  ClAP  Operational  Activities  (SV-5) 


System  Functions 

TAMD  Operational  Activities 

A1 

Monitor 

A2 

Assess 

A3 

Plan 

A4 

Execute 

A5 

Sustain 

Single  Sensor 
Sense (SS) 

Search 

Horizon  Air  Active 

Al.1.1 

A4.2.1 

Horizon  Air  Passive 

Al.1.1 

A4.2.1 

Above  Horizon 

Active 

Al.1.1 

A4.2.1 

Above  Horizon 

Passive 

Al.1.1 

A4.2.1 

OTH  Active 

Al.1.1 

A4.2.1 

OTH  Passive 

Al.1.1 

A4.2.1 

Track 

Al.1.2, 

Al.1.3 

A4.2.2.1 

Feature  Extraction 

Al.1.3 

A2.2.3 

A4.2.2.2 

Identification 

Al.1.3 

A2.2.3 

A4.2.2.2 

Multi-Sensor 
Sense  (MS) 

Multi-Sensor  Data  Alignment 

A2.2.1 

Temporal  Data 
Alignment 

A2.2.1 

Spatial  Data 
Alignment 

A2.2.1 

Multi-Sensor  Data  Association 

A2.2.1 

Common  Track  File  Generation 

A2.2.2 

Update  Existing 

Tracks 

A2.2.2 

Initiate  New  Track 

A2.2.2 

Track  File  Culling 

A2.2.2 

Common  ID 

A2.2.3 

A4.2.2.2 

Situational 

Assessment 

(SA) 

Tactical  Picture  Generation 

Develop  Tactical 
Picture 

A4.1.2 

A5.2.1 

Update 

tracks 

A4.1.2 

Update 

intel 

A4.1.2 

Update 

topo. 

info. 

A4.1.2 

Update 
env.  info 

A4.1.2 

Update 
ops.  data 

A4.1.2 

Engagement  Status  Tracking 

A4.1.2 

Battle  Damage  Assessment 

A4.2.4 

Alert  Generation 

A2.4 

A4.1 
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Plan  (P) 

Force  Planning 

A3.1 

Operations  Planning 

A3. 2, 
A3.3 

A5.1 

Plan  CIAP 

A3.2.2.1 

Identify 

sensor 

resources 

A3.2.2.1 

Deter¬ 

mine 

sensor 

locations 
&  sector 
responsi¬ 
bilities 

A1.2 

A3.2.2.1 

Mission  Planning 

AL2.2 

Mission  Modeling/Simulation 

A3. 2, 
A3. 3 

A5.1 

Model  CIAP  Coverage 

A3.2.2.1 

Generate 
CIAP 
emp.  recs. 

A3. 1.1 

Generate 

CIAP 

contin¬ 

gency 

coverage 

A3. 1.1 

Environmental  Prediction 

A3. 2 

Decision  (D) 

Target  Prioritization 

A4.1.3 

Target-Weapons  Pairing 

A4.1.3 

Dynamic  Deconfliction 

A4.1.1 

Force 

Positioning 

(FP) 

Platforms  Transport 

A5.2 

Systems  Transport 

A5.2 

Engagement 

Execution 

(EE) 

Weapon  Initialization  &  Launch 

A4.2.3 

Fire  Control 

A4.2.3 

Illumination 

A4.2.3 

Intercept 

A4.2.3 

Battle  Damage  Indication 

A4.2.3 

Electronic  Attack 

A4.2.3, 

A4.3.1 
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CSD  Comms 

AL3 

A2.3 

CSD 

CSD  Networking 

A1.3 

A2.3 

CSD  Services 

A1.3 

A2.3 

CFO  Comms 

A3. 4 

CFO 

CFO  Networking 

A3. 4 

CFO  Services 

A3. 4 

CO  Comms 

A4.1.4 

A5.3 

Interoperate 

CO 

CO  Networking 

A4.1.4 

A5.3 

CO  Services 

A4.1.4 

A5.3 

CS  Comms 

A4.3.3 

CS 

CS  Networking 

A4.3.3 

CS  Services 

A4.3.3 

Gen  &  Comm  Time 

A1 

A2 

A3 

A4 

A5 

PNT 

Gen  &  Comm  Nav 

A1 

A2 

A3 

A4 

A5 

Gen  &  Comm 
METOC 

A1 

A2 

A3 

A4 

A5 

*Note:  CIAP  functions  are  shown  in  italics. 


CIAP  System  Interface  Mapping 

The  physical  instantiation  of  the  architecture  is  the  next  step  for  the  Coalition.  Each  Coalition 
Partner  is  identifying  the  systems  and  platforms  that  will  be  CIAP  compatible.  From  this  data,  a 
system-to-functions  mapping  will  be  developed,  as  well  as  system-to-system  mappings  and 
system  interface  mappings  identifying  connectivity,  data  content,  data  format,  and  link  protocol. 
An  example  of  such  system  mappings  (SV-3)  for  a  selected  set  of  U.S.  Navy  systems  is  provided 
in  Figure  7-5.  This  figure  illustrates  three  types  of  system  mappings: 

•  System-to-system  mapping  (SV-3  a) 

•  System-to-platform  mapping  (SV-3b) 

•  System-to-system  mapping  (SV-3c) 

Figure  7-6  is  a  graphical  representation  of  the  system  interfaces. 

Architecture  Performance  and  Behavior 

An  executable  model  of  the  architecture  will  be  developed  to  validate  the  CIAP  concept  and  to 
provide  an  early  demonstration  that  the  physical  instantiation  will  meet  the  Capstone 
Requirements.  The  executable  model  at  the  highest  level  will  have  the  logical  connectivity 
depicted  previously  in  Figure  7-3,  the  Logical  Relations  of  the  Activity  Model.  The  high-level 
activities  will  be  decomposed  into  operator  models  or  system  models  and  executed  in  use  cases. 
If  a  common  database  representing  the  CIAP  can  be  created  and  assessed  against  the  Capstone 
Requirements  using  the  executable  architecture,  then  the  Coalition  could  begin  design  and 
development.  Limitations  and  issues  including  available  communication  bandwidth,  inaccurate 
time  references,  or  inaccurate  platform  positional  accuracies  can  be  addressed  using  the 
executable  architecture  before  proceeding  with  more  costly  design,  development,  and 
experimentation  efforts. 

The  executable  model  provides  the  ability  to  determine  if  the  architecture  will  function  under 
simulated  real-world  conditions.  Before  undertaking  development  of  an  executable  model,  it  is 
critical  to  review  the  static  views  of  the  architecture  of  the  proposed  implementation  to  verify  fhe 
following  considerations: 
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CIAP  System-to-Platform  Mapping  (SV-3b) 

Systems 

Platform  Types 

CG(X) 

CVN 

DDG  51 

E-2C 

AN/SPY-1  D(V) 

X 

CEC  Block  2 

X 

X 

X 

X 

E-2C  MC 

X 

GCCS-M  4.x 

X 

X 

X 

Link-16 

X 

X 

X 

X 

MFR 

X 

Open  Architecture 

X 

X 

RMP  (E-2C) 

X 

SSDS  MK  2 

X 

TAMD-S 

X 

TAMD-X 

X 

VSR 

X 

System-to-Function  Mapping  (SV-3a) 

Networks 

Sensors 

BFC2 

Functions 

I 

8 

I  Open  Architecture  | 

Q 
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Figure  7-5.  System  Mappings  (SV-3),  U.S.  Navy  Systems  (circa  2019) 


Figure  7-6.  System  Interface  Description  (SV-1) 
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•  Required  system  interfaces  exist  and  the  architecture  adequately  defines  these  interfaces 

•  Required  data  is  being  passed  from  system  to  system  at  these  interfaces  to  support  system-of- 
system  mission  functionality 

•  The  flow-down  of  requirements  is  clear  and  that  the  overall  system-of-system  requirements 
can  be  successfully  achieved  through  the  requirements  of  individual  systems 

•  Interoperability  between  systems  is  adequately  defined  and  supported  by  the  system 
architecture 

•  The  impact  of  functionality  that  is  redundant  across  multiple  systems  is  clearly  understood 

•  Required  functionality  that  is  omitted  is  identified  and  corrective  actions  are  taken 

•  Coordinating  functionality  critical  to  FoS  performance  is  identified 

Once  the  implementation  is  verified,  development  of  an  executable  model  will  begin. 

The  CIAP  executable  model  will  validate  that  the  architecture  is  functional.  In  order  to 
accomplish  this  validation,  the  CIAP  architecture  must  be  placed  in  a  use  context.  Specifically, 
the  use  context  for  CIAP  is  Theater  Air  Defense;  in  other  words,  CIAP  exists  for  the  expressed 
purpose  of  enabling  Theater  Air  Defense.  Consequently,  the  evaluation  of  CIAP  requires  that 
Theater  Air  Defense  be  modeled  in  the  executable. 

The  OV-6c  for  Theater  Air  Defense  is  provided  in  Figure  7-7.  CIAP  functionality  is  resident  in 
the  purple  shaded  blocks  of  the  figure.  This  OV-6c  will  be  represented  in  a  UML  model.  The 
model  will  be  structured  and  of  sufficient  fidelity  to  determine  the  effect  on  engagement  success 
of  the  following  issues: 

•  Inter-platform  bandwidth  limitations 

•  Inter-platform  communication  network  QoS  policy 

•  Targeting  data  routing  from  sensor  to  shooter 

•  Latency  delays  due  to  human  interpretation  of  combat  ID  vs.  automatic  target  ID 

•  Target  loading  on  the  communication  network 

•  Interceptor/Weapon  time  of  flight 

The  first,  second,  third,  and  fifth  items  are  directly  related  to  CIAP  performance. 


Figure  7-7.  Theater  Air  Defense  OV-6C 
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The  executable  model  will  be  used  to  support  the  following  specific  purposes: 

•  Generation  of  data  on  the  dynamic  interactions  of  the  component  portions  of  the  Theater  Air 
Defense  system  (e.g.,  sensor,  communication  link,  weapon)  and  the  overall  system  response 
time  performance 

•  Identification  of  the  interactions  and/or  components  that  have  the  greatest  impact  on  overall 
Theater  Air  Defense  system  response  time  performance 

•  Determination  of  the  expected  impacts  on  Theater  Air  Defense  performance  from  changes 
(such  as  a  different  mix  of  platforms  or  platform  placement)  or  enhancements  (such  as  faster 
interceptors/weapons,  automation  of  target  ID,  or  increased  bandwidth) 


Approach 

An  active  agent  executable  model  will  be  developed  in  an  iterative,  hierarchical  fashion  using 
Rational  Rose  Real-Time.  The  model  will  portray  the  Theater  Air  Defense  operational 
architecture  and  Theater  Air  Defense  system  architecture  starting  at  a  high  level.  Detail  will  be 
added  to  the  model  as  needed  in  order  to  address  system  performance.  System  performance  data 
for  each  modeled  system  will  be  documented  in  a  System  Performance  Parameters  Matrix  (SV- 
7).  The  model  will  represent  the  sensor-shooter-target  sequence  using  agents  to  portray  the  major 
system  components:  ship  platforms,  communications  links,  weapons/interceptors,  and  decision 
makers.  Functions  and  or  activities  performed  within  an  agent  are  to  be  initially  portrayed  as 
passive  objects  having  a  time  delay  and  subsequently  as  active  objects  modeling  the  propagation 
of  targeting  errors.  The  model  is  notionally  shown  in  Figure  7-8. 


Targets 

- ►  Threats  negated 

•  Friend/foe 

_ ^ 

TMD 

- ►  Fratricide 

•  Location 

Model 

- ►  Weapon  efficiency 

•  Kinematic 

- ►  Asset  protection 

Figure  7-8.  Notional  Active  Agent  Executable  Model  for  CIAP 


Functions  will  be  modeled  as  a  data  transform  f  (x)  with  a  time  delay.  The  least  level  of  fidelity 
will  be  modeled  to  represent  the  data  transform  adequately.  Figure  7-9  illustrates  the  method  for 
modeling  functions. 


Figure  7-9.  Method  for  Modeling  Functions 


Activities  will  be  modeled  as  data  transform  g  (y)  with  a  time  delay.  Figure  7-10  illustrates  the 
method  for  modeling  activities. 


y(t) - >• 

Activity 

g  (y- 1) 

- ►  y(t+^t) 

J^igure  7-10.  Method  for  Modeling  Activities 
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Various  characteristics  of  system  eomponents  will  be  addressed  in  the  model.  These 
characteristics  are  identified  by  system  component  in  Table  7-3. 

Table  7-3 


System  Component  Characteristics  to  be  Addressed  in  the  Model 


System  Component 

Characteristics 

Sensor 

Target  state  error  estimation  due  to  sensor  measurement  error  and 
sensor  registration  errors 

Communications  Link 

Data  transfer  times  arising  from  congestion,  satellite  visibility  and 
bandwidth  limitations  as  well  as  QoS  policies 

Launch  Platform 

Launch  platform  registration  errors  and  time  required  to  maneuver  to 
launch  position 

Weapons 

Weapon  registration  errors,  sensor  measurement  and/or  guidance 
errors,  and  time-of- flight 

Control  Platforms 

Control  platform  registration  errors,  sensor  fusion  errors,  and  the  time 
required  to  interpret  sensor  data  and  determine  an  engagement  order 

The  model  will  be  eonfigured  to  evaluate  the  stochastic  effects  of  network  loading.  These  effeets 
will  be  evaluated  by  developing  a  scene  generator  that  will  inelude  parameters  including  a 
minimum  and  maximum  number  of  targets,  spatial  and  temporal  distribution,  and  spatial  and 
temporal  visibility.  Sensor  parameters,  ineluding  probability  of  detection  as  a  function  of  target 
visibility  and  spatial  and  temporal  coverage,  will  also  be  developed.  The  model  will  also  include 
minimum  and  maximum  numbers  of  launeh  and  control  platforms  and  spatial  and  temporal 
distributions. 

Data  collected  during  execution  of  the  model  will  be  used  to  produce  graphs  and  plots  that  will 
portray  system  behavior  and  performanee.  To  support  analysis,  the  model  will  produce  the 
following  products: 

•  Time  line  of  aetivities 

•  Latency  from  sensor  to  weapon  impaet 

•  Error  propagation  from  sensor  to  weapon 

•  Probability  of  engagement  suceess  in  the  following  categories: 

Target  not  visible 

Target  visible,  but  latency  of  engagement  was  too  great 
Target  visible,  engagement  prosecuted,  but  targeting  error  was  too  great 
Target  visible,  engagement  a  sueeess 
Weapon  efficiency 

Specific  CIAP  metrics  will  be  derived  that  show  the  effeet  of  the  CIAP’s  accuracy  on  each  of  the 
listed  Theater  Air  Defense  performance  metrics.  While  this  approach  requires  the  development 
of  an  executable  that  will  be  mueh  more  eomplicated  than  an  exeeutable  of  just  the  CIAP 
process,  this  approach  is  necessary  to  place  the  value  of  the  CIAP  in  context.  For  example,  if 
CIAP  accuracy  can  be  increased  20  pereent  but  has  minimal  effeet  on  Theater  Air  Defense 
engagement  success,  time  and  funding  that  increase  CIAP  accuracy  to  that  level  may  be  better 
spent  elsewhere.  In  this  context,  a  CIAP  is  a  means  to  an  end,  not  an  end  in  itself 
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Summary 

The  CIAP  architecture  development,  while  in  its  infancy,  has  proven  to  be  a  worthwhile  tool  for 
instantiating  the  CIAP  concept.  The  use  of  standardized  views  of  the  architecture  accessible  via  a 
collaborative  engineering  environment  has  enabled  a  worldwide  coalition  to  greatly  accelerate 
the  CIAP  systems  engineering  process  despite  the  wide  geographical  and  time  differences  among 
the  partners. 
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PART  III 

CAPABILITIES-BASED  ACQUISITION 

This  final  part  of  the  book  focuses  on  the  methodology  for  using  the  Architecture  Framework  to 
support  research,  development,  and  acquisition,  and  particularly  capabilities-based  acquisition. 
The  first  chapter  in  this  part  of  the  book  provides  the  history  of  the  Architecture  Framework  and 
the  relevance  of  that  history  to  mission  capability  acquisition.  It  then  continues  with  a  discussion 
of  the  rationale  behind  the  move  to  capability-based  acquisition  and  provides  information  on  the 
conditions  under  which  the  pursuit  of  FoS  interoperability  can  offer  performance  and  cost- 
effectiveness  benefits.  The  second  and  final  chapter  in  this  part  of  the  book  addresses  the  data 
management  aspects  of  the  architecture-based  systems  engineering  methodology.  As  seen  in  the 
case  studies  provided  in  Part  II  of  the  book,  the  complexity  of  the  FoS  combined  with  the 
diversity  of  the  stakeholders  demand  the  use  of  automation  and  standards  in  the  data 
management  of  the  architecture  products.  This  chapter  provides  methodology  and  tools  for 
incorporating  data  management  in  the  mission  capability  acquisition  process. 
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CHAPTER  8 

CAPABILITY-BASED  ACQUISITION:  WHY,  WHEN,  AND  HOW? 


Purpose 

The  previous  chapters  demonstrated  how  the  architectural  methodology  can  be  applied  to 
specific  FoS  systems  engineering  initiatives  focused  on  increasing  mission  capability.  This 
chapter  provides  information  on  the  architecture  framework  history  and  the  relevance  of  that 
history  to  mission  capability  acquisition  today.  It  describes  the  reasons  for  pursuing  capability- 
based  acquisition  and  recognizes  that  the  failure  to  achieve  the  synergy  possible  through  FoS 
systems  engineering  can  lead  to  degradation  in  combat  effectiveness.  It  also  introduces 
challenges  associated  with  using  an  FoS  approach  to  acquire  integrated  systems  focused  on 
achievement  of  defined  mission  capabilities  and  notes  that  it  is  not  always  feasible  or  cost 
effective  to  force  system  interoperability  into  an  FoS.  Because  providing  interoperability  may 
require  development  of  costly  solutions,  the  resulting  performance  gains  sought  from  the 
interoperation  of  systems  must  be  significant  in  order  to  justify  the  investment.  Finally,  it 
introduces  a  basis  application  of  architectures:  documentation  of  a  blueprint  for  FoS 
development. 

Architecture  Framework  History  and  Relevance  to  Mission  Capability  Acquisition 

In  1996,  the  OASD  for  C3I  (today  called  Nil)  sponsored  an  effort  to  develop  an  Architecture 
Framework  Document  in  order  to  establish  a  standard  means  for  the  department  to  describe 
integrated  systems.  In  seeking  to  provide  joint  and  interoperable  systems,  the  department 
believed  the  first  step  should  be  development  of  a  common  lexicon  and  approach  that  could  be 
used  to  describe  integrated  architectures  across  disparate  organizations.  The  Services,  Joint  Staff, 
Office  of  the  Secretary  of  the  Defense,  and  agencies  across  the  department  worked  together  to 
develop  this  lexicon  and  approach  document.  Because  the  effort  was  sponsored  by  the  OASD  for 
C3I,  however,  the  resultant  document,  the  C4ISR  Architecture  Framework  Version  1.0,  focused 
entirely  on  architecture  views  that  would  be  used  to  describe  the  integration  of  C4ISR  systems. 
The  architecture  views  provided  in  the  document  were  derived  primarily  from  selected  views 
that  were  used  across  the  department  to  describe  information  systems  and  information  networks. 
Despite  the  fact  that  the  end-product  from  this  exercise  had  a  somewhat  narrow  focus,  the 
attempt  to  organize  common  views  across  organizations  that  were  dealing  with  requirements, 
engineering,  and  acquisition  was  a  step  in  the  right  direction. 

The  C4ISR  Architecture  Framework  Version  1.0  included  various  views,  categorized  as 
operational,  system,  or  technical,  that  could  be  used  or  modified  to  support  design  of 
interoperable  and  integrated  systems  of  systems.  The  views  are  illustrated  in  Figure  8-1.  They  are 
similar  in  many  ways  to  the  classic  systems  engineering  views  of  the  Institute  of  Electrical  and 
Electronics  Engineers  (IEEE)  Standard  610.12^^  in  that  both  use  functional  and  physical  views  to 
capture  requirements  and  identify  designs  for  improving  performance.  The  difference  in  the 
C4ISR  Architecture  Framework  was  its  focus  on  the  improvement  of  C4ISR  interoperability. 
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Figure  8-1.  Architecture  Framework’s  Common  Language  and  Standard  Format,  including 
Operational,  Systems,  and  Technical  Views 

In  December  of  1997,  the  second  version  of  the  C4ISR  Architecture  Framework  was  published 
and  eventually  led  to  the  convening  of  the  DoD  Architecture  Working  Group  in  June  2002.  This 
group  developed  definitions,  guidelines,  and  references  (Volume  I),  products  and  data 
descriptions  (Volume  II),  and  supplementary  guidance,  sample  products,  and  use  (Volume  III) 
for  the  DoD  Architecture  Framework  (DODAF).  The  major  new  features  of  the  DODAF  are 
summarized  in  the  following  bullets: 

•  Based  on  intended  use  of  the  document  across  three  major  disciplines 

•  Mapped  to  the  Federal  Enterprise  Framework 

•  Removes  concept  of  Essential  and  Supporting  Products 

•  Incorporates  data-centric  perspective 

•  Provided  Object-Oriented  and  NOW  approaches 

The  drafts  of  the  three  volumes  of  the  DODAF  were  submitted  for  review  in  early  2003. 

Mission  capability  based  acquisition  relies  on  the  establishment  of  an  architecture  framework 
within  which  individual  programs  can  be  evaluated  against  requirements.  Operators  must  create 
operational  views  to  capture  integrated  requirements,  and  engineers  and  systems  acquisition 
professionals  must  use  systems  and  technical  views  to  evaluate  investment  strategies  in 
determining  the  best  methods  for  satisfying  the  integrated  operational  requirements.  The  OASD 
for  C3I  recognized  this  fundamental  need  to  evaluate  what  have  come  to  be  known  as  “derived 
requirements  for  interoperability  and  integration.”  The  department  established  instructions  and 
policies  to  promote  better  communication  between  the  operational,  engineering,  and  acquisition 
communities  and  their  respective  disciplines  in  order  to  support  improved  identification  of 
technical  and  programmatic  requirements. 
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Development  of  the  Arehitecture  Framework  Doeument  was  the  first  step  toward 
implementation  of  a  standard  process  for  evaluating  interoperability  and  integration  because  it 
created  a  common  approach  and  language  to  support  the  process.  Achievement  of  this  goal  was 
subsequently  moved  forward  through  establishment  of  requirements  for  specific  program 
reviews  and  direction  to  use  specific  common  tools  across  departments  to  promote 
standardization  in  those  reviews.  For  example,  the  OASD  for  C3I  began  requiring  the  use  of 
operational,  systems,  and  technical  views  as  part  of  the  C4ISPs  that  were  required  by  the  DoD 
5000  acquisition  directive  to  be  included  in  program  reviews  for  major  acquisition  milestones. 
Figure  8-2  illustrates  the  C4ISP  process.  Additionally,  the  OASD  for  C3I  has  established  a 
process  for  disseminating  architecture  views  for  widespread  review  and  analysis.  After  reviewing 
each  C4ISP,  the  OASD  for  C3I  staff  places  the  architecture  views  in  the  JMAAT.  Because 
JMAAT  is  networked  via  SIPRNET  through  the  department,  the  views  are  accessible  to  and 
reviewable  by  more  than  120  subject  matter  experts  throughout  the  Services,  Combatant 
Commanders,  and  agencies.  These  experts  review  the  views,  study  and  discuss  the  technical  and 
programmatic  issues  identified,  and  determine  how  they  may  impact  Joint  mission  areas  and  any 
desired  capabilities.  This  process  along  with  the  others  described  in  this  paragraph  point  to  the 
emergence  of  a  formal  process  for  addressing  critical  technical  and  programmatic  issues  that 
affect  system  interoperability,  integration,  and  mission  capability. 


First,  define  and  Then,  analyze  and 

describe  evaluate 


Note  1 :  Chapters  should  he  developed  in  sequential  fashion 
Note  2:  Highly  recommend  the  Strategy-To-Task  methodology 

Figure  8-2.  C4ISP  Process  Chart 


What  is  Capability-Based  Acquisition? 

Single  system  and  platform-centric  SoS  acquisition  has  historically  focused  on  defeating  a 
specific  threat  or  related  family  of  threats.  Capabilities-based  acquisition  focuses  on  achieving 
mission  capabilities,  usually  through  an  assembled  FoS  or  through  an  SoS. 
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To  understand  capability-based  acquisition,  it  is  important  to  understand  what  the  terms  in  the 
title  actually  mean.  Recall  from  Chapter  2  that  an  operational  concept  is  an  end-to-end  stream  of 
activities  that  defines  how  force  elements,  systems,  organizations,  and  tactics  combine  to 
accomplish  a  military  task.  Within  a  scenario  or  tactical  situation,  a  course  of  action  (COA)  is  a 
possible  plan  available  to  an  individual  or  commander  that  would  accomplish  or  support  a 
mission.  A  capability  then,  as  defined  by  Joint  doctrine,  is  the  ability  to  execute  a  specified  COA. 
COAs  are  simply  sequences  of  operations  that  can  be  executed  to  support  or  accomplish  a 
mission,  so  mission  capability  can  be  defined  as  the  ability  to  execute  the  collective  COAs 
necessary  to  accomplish  the  overall  mission.  It  is  for  this  reason  that  every  case  study  in  Part  II 
of  this  book  includes  an  Operational  Event/Trace  Description  (OV-6c)  that  provides  the 
operational  concept  for  the  mission  capability.  Capability-based  acquisition  can  then  be  defined 
as  the  acquisition  of  an  interoperable  FoS  or  SoS  that  enables  the  execution  sequence  described 
in  the  OV-6c  for  a  specific  mission  or  mission  task. 

Why  Capability-Based  Acquisition? 

The  background  information  provided  in  the  previous  two  sections  of  this  chapter  offers  some 
insight  on  the  rationale  behind  capability-based  acquisition,  but  the  bottom  line  is  that  fiill 
mission  capability  can  only  be  achieved  when  systems  are  fully  integrated,  interoperable,  and 
combined  with  appropriate  DOTMLPF  components.  Failure  to  achieve  this  synergy  can  degrade 
combat  effectiveness.  The  FoS  engineering  and  acquisition  process  is  designed  to  enable 
capabilities  from  an  assemblage  of  systems  designated  to  support  mission  objectives.  Realizing 
the  criticality  of  full  systems  integration  in  combat  operations  for  specific  mission  areas,  the 
DoD  began  exploring  the  possibility  of  using  a  mission  capability-based  acquisition  process  to 
develop  new  investment  strategies  that  would  satisfy  integrated  requirements  with  analytically 
based  program  decisions. 

Degradation  in  Combat  Effectiveness 

Degradation  in  combat  effectiveness  can  be  caused  by  many  contributing  factors,  one  of  which  is 
undeniably  poor  or  non-existent  integration  or  interoperability.  The  inability  of  systems  to  work 
collaboratively  may  make  the  systems  unable  to  perform  functions  that  are  essential  to  the 
support  of  operator  activities.  Because  integration  and  interoperability  are  so  critical  to  combat 
effectiveness,  the  entire  FoS  must  be  considered  in  the  engineering  and  acquisition  process  if 
decision  makers  are  to  choose  the  most  operationally  sound,  technically  feasible,  and  cost 
effective  program  investments. 

Evidence  of  the  need  for  an  FoS  approach  to  the  engineering  and  acquisition  process  is 
unfortunately  abundant.  In  recent  combat  missions,  the  lack  of  integrated  systems  and  their 
inability  to  perform  vital  functions  in  a  coherent  fashion  have  contributed  to  difficult  situations 
and  significant  problems  in  executing  military  operations.  A  primary  symptom  of  poor 
integration  and  interoperability  is  the  inability  of  systems  to  provide  and  share  timely  and 
accurate  information  among  key  system  components.  This  inability  frequently  leads  to  a  failure 
in  providing  the  right  information  at  the  right  place  and  time,  which  in  turn  can  lead  to  incorrect 
decisions,  mistaken  identifications,  and  slow  response  times.  Lessons  learned  from  recent 
military  operations  have  highlighted  information  distribution  problems  that  led  to  catastrophic 
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and  fatal  errors  including  friendly  fire  incidents,  the  shooting  down  of  neutral  forces,  and  the  loss 
of  U.S.  forces  from  enemy  attacks  that  may  have  been  prevented  if  friendly  forces  had  been 
provided  with  more  timely  and  accurate  warnings. 


While  the  need  for  an  FoS  approach  to  acquisition  and  systems  engineering  may  be  clear, 
difficulty  exists  in  moving  from  the  way  systems  are  acquired  and  engineered  today  to  the  end 
state  desired.  The  dilemma  is  illustrated  and  described  in  Figure  8-3. 


Figure  8-3.  The  Dilemma  Chart 


A  variety  of  technical  issues  and  problems  have  prevented  not  only  the  integration  of  emerging 
multiple  systems  that  provide  related  functions  but  also  the  satisfaction  of  newly  evolving 
requirements  for  legacy  systems  that  were  not  initially  designed  to  operate  together.  Examples 
include  the  inability  to  put  multiple  tracks  from  various  systems  together  in  a  single  integrated 
tactical  picture  (as  shown  in  Figure  8-4)  and  the  confusion  and  errors  in  plotting  locations  and 
positions  caused  by  the  delivery  of  specific  information  to  receiving  units  using  different  metrics 
and  standards.  In  other  examples,  root  cause  analysis  has  shown  that  the  inability  to  integrate 
various  communications  links  led  to  delays  in  the  speed  of  command  and  contributed  to 
confusion  in  the  tactical  pictures.  In  short,  there  can  be  no  doubt  that  the  failure  to  employ  an 
FoS  approach  to  the  engineering  and  acquisition  process  has  led  to  both  degradation  in  mission 
capability  and  catastrophic  consequences. 

The  failure  to  use  an  integrated  systems  planning,  design,  and  acquisition  process  creates 
additional  problems  beyond  critical  operational  errors  and  challenges.  It  also  significantly 
increases  the  cost  of  providing  associated  and  essential  capabilities  necessary  to  support  systems 
and  processes  across  all  service  branches.  Specifically,  the  cost  of  installing,  maintaining,  and 
providing  training  on  duplicate  systems  designed  to  perform  overlapping  functions  in  support  of 
required  operator  activities  is  a  poor  investment  of  funds  that  could  be  applied  to  other,  more 
critical  priorities. 
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"igure  8-4.  Multi-Track  on  Single  Target  Chart 


In  studying  the  integration  and  interoperability  problems  DoD  faees,  an  alarming  trend  has 
become  apparent.  This  trend  indicates  the  DoD’s  tendency  to  invest  funds  into  systems 
development  aimed  at  extending  capabilities  already  provided  by  existing  systems.  In  many 
eases,  these  development  efforts  have  been  undertaken  even  when  the  development  effort  will 
yield  only  limited  functional  improvement  while  imposing  significantly  increased  costs  for 
training,  maintenance,  and  installation  of  essentially  duplieative  systems.  The  trend  also  shows  a 
simultaneous  avoidance  of  investment  in  systems  that  are  not  eompletely  developed  but  offer 
potential  solutions  to  identified  eapability  gaps.  Because  the  systems  are  not  fully  developed, 
they  are  higher  risk  projects  and  their  technical  objectives  are  more  difficult  to  achieve,  yet  it  is 
only  through  investment  in  these  types  of  projeets  that  total  system  capability  gaps  can  be 
addressed.  To  reverse  this  trend  of  investing  in  duplicative  systems  and  ignoring  identified 
capability  shortfalls,  it  is  necessary  to  approaeh  the  acquisition  and  engineering  process  with  a 
goal  of  gaining  an  integrated  FoS  that  can  deliver  specific  mission  capabilities. 

What  is  a  Mission  Capability  Package? 

To  address  the  need  to  provide  integrated  FoSs  designed  to  deliver  a  specific  set  of  capabilities. 
Mission  Capability  Packages  were  ereated.  Mission  Capability  Paekages  include  portfolios  of 
analytically  backed  programs  combined  with  the  necessary  DOTMLPF  components  to  allow 
satisfaetion  of  integrated  requirements.  These  packages  are  developed  to  identify  systems  and 
support  elements  needed  to  meet  mission  objectives  defined  and  validated  by  the  operators. 

Developing  a  Mission  Capability  Package  requires  use  of  an  integrated  progression  of 
assessment  processes  and  arehitecture  produets.  These  proeesses  and  produets  build  upon  each 
other  to  provide  the  best  and  most  achievable  evolution  plan  and  business  case  for  the  required 
capability  objectives  that  support  the  specified  mission  areas.  A  complete  Mission  Capability 
Package  accounts  not  only  for  the  systems  but  also  for  the  DOTMLPF  required  to  obtain  a 
desired  joint  mission  area  capability.  Figure  8-5  provides  further  definition  of  an  MCP. 
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Mission  Capability  Packages  (MCPs)  are  an  Alignment  Tool 


What’s  an  MCP? 

*  Introduced  by  the  concept  of  Network  Centric  Warfare  /  Operations 

*  A  task-organized  "bundle"  of ... 

CONOPS,  processes  and  organizational  structures 

Networks,  sensors,  weapons  and  systems 

The  people,  training  and  support  services  to  sustain  it 


An  MCP  treats  all  of  the  above  not  as  a 
collection  of  things  and  processes  -- 
but  as  an  integrated  system 


Architectures  should  be 
aligned  to  MCPs 


Note:  An  MCP  is  not  a  mission  area  but  could  be  an  acquisition  business  unit 

Source:  “Integration,  Interoperability  and  Architectures",  CAPT  J.  Yurchak,  Assessment  Division  (OPNAV  N81)  dtd  28  Feb  2001 

Figure  8-5.  MCP  Definition  Chart 

One  of  the  primary  DoD  objectives  outlined  by  the  Joint  Staff  in  the  Joint  Vision  2010  and  2020 
documents  and  other  DoD  planning  and  policy  documents  during  the  past  10  years  has  been  to 
acquire  joint,  interoperable  FoSs  that  improve  mission  capability  and  increase  combat 
effectiveness  and  efficiency.  More  recently,  the  Navy  and  the  Air  Force  have  begun  to  develop 
processes  for  evaluating  their  POM  investment  strategies  through  the  use  of  Mission  Capability 
Packages.  These  services  are  using  the  packages  to  identify  and  eliminate  gaps  and  duplications 
in  program  investments  and  to  make  better  investment  decisions  that  will  provide  the  end-to-end 
processes  and  equipment  necessary  to  improve  military  operational  capabilities. 

The  U.S.  Navy’s  Mission  Capability  Package  process  is  outlined  in  the  Chief  of  Naval 
Operations  N70  POM-06  Process.  The  process,  which  is  graphically  outlined  in  Figure  8-6,  is  a 
process  for  standardizing  scenarios,  capability  objectives,  and  metrics  to  assess  acquisition 
decisions.  It  describes  the  processes  for  developing  Mission  Capability  Packages  and  the 
organizations  responsible  for  creating  them.  The  process  was  initiated  by  the  CNO  and 
conducted  by  the  office  of  Integrated  Warfighter  Requirements  (OPNAV  N70).  The  packages 
developed  using  the  process  will  be  used  in  building  an  Integrated  Sponsor  Planned  Program 
(ISPP)  that  will  guide  acquisition  decision-making  in  the  POM. 

The  RDA  CHENG  applied  the  architectural  methodology  to  support  the  N70  POM  04  build.  The 
methodology  was  used  in  six  of  the  N70  MCPs  to  various  levels.  In  supporting  the  N70  POM  04 
build,  a  cost  analysis  was  performed  on  the  various  Programs  of  Record  based  on  program  lines 
and  lifecycle  costs.  The  cost  analysis  was  followed  by  a  Multi-Attribute  Utility  Analysis,  as 
described  in  Chapter  5.  The  Multi-Attribute  Analysis  was  used  to  develop  organizing  exhibits  at 
the  early  stages  of  planning  for  POM  04,  although  the  exhibits  were  not  used  in  the  final 
decision-making  process.  The  ASN(RDA)  CHENG  did  use  the  Multi-Attribute  Utility  Analysis 
to  advise  ASN(RDA). 
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Figure  8-7  shows  the  eurrent  proeess  being  proposed  at  the  Joint  level  by  CJCS  J8.  This  process 
is  clearly  architecture-based  and  maps  acquisition  planning  and  DOTMLPF  into  capability 
evolution,  as  shown  in  the  lower  half  of  the  figure.  The  figure  also  illustrates  the  concept  of 
identifying  capabilities  as  bundles  of  tasks  and  of  associating  multiple  systems  with  capabilities. 


Concepts 


Architectures 

\ 


capability 
task  a 
task  b 
task  c 


Capability  Roadma 


2010  2012  2014  2016 


Assessment 

capability  capability  capability 


task  task  task  task  task  task  task 

abed  e  f  g 


a 

¥ 

u 

u 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

• 

Resource  Strategy 

sys  1 

sys  3  block  new  sys 
SLEP  upgrade  FOC 


SLEP  upgrade  FOC 

\v,> 


sys  2 
end  of  SVC  life 


2004  2006 


training 

change 


capability 


field  new 
organization 


Figure  8-7.  CJCS  J8  Proposed  Capabilities-Based  Methodology 
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Why  Change  the  Process? 

As  noted  throughout  this  chapter,  the  current  acquisition  process  does  not  address  methods  for 
acquiring  integrated  FoSs  that  can  meet  specific  mission  objectives.  Current  requirements 
generation  processes  generally  fail  to  produce  an  integrated  FoS  view  that  can  identify  all 
systems  and  support  elements  required  for  successful  execution  of  operator  activities.  The 
process  focuses  on  improvements  to  individual  systems  and  platforms  as  opposed  to  integration 
and  interoperation  of  systems  and  platforms  to  produce  desired  capabilities,  which  inevitably 
leads  to  continued  acquisition  of  and  investment  in  programs  with  systemic  interoperability 
problems.  The  problem  is  exacerbated  by  the  fact  that  the  decision  process  is  frequently 
uncoordinated  and  out  of  sync  with  related  decision-making  activities,  so  it  often  fails  to  put  the 
right  piece  of  the  solution  in  service  at  the  right  time.  Simply  put,  DoD  cannot  meet 
interoperability  objectives  by  merely  establishing  or  enforcing  policies  or  standards,  including 
key  performance  parameters  in  ORDs  or  Capstone  Requirments  Documents  (CRDs),  or  even  by 
applying  sound  engineering  and  computer  science  practices.  Only  through  the  use  of  an 
acquisition  decision  making  process  that  specifically  addresses  integrated  FoS  mission  capability 
can  DoD  begin  to  meet  its  interoperability  goals. 

The  need  to  make  results-based  acquisition  decisions  serves  as  an  effective  forcing  function  for 
changing  the  process.  The  use  of  Mission  Capability  Packages,  which  include  the  architectural 
views  and  assessment  processes  for  considering  the  integrated  requirements  and  associated 
DOTMLPF  components  needed  to  provide  and  field  the  desired  capabilities,  will  enable  DoD  to 
make  better  acquisition  decisions  focused  on  mission  objective  achievement. 

What  Needs  To  Be  Done? 

Changing  the  acquisition  process  to  address  mission  capability  will  involve  a  collaborative  effort 
among  operators,  engineers,  and  acquisition  specialists  to  perform  the  following  key  steps: 

•  Develop  a  framework  and  language  that  will  assist  operators,  engineers,  and  acquisition 
specialists  in  identifying  integrated  solutions  that  provide  a  balance  between  platform  and 
system  capabilities  and  force  capabilities 

•  Determine  integrated  requirements  and  perform  gap  analysis  based  on  the  architecture 
framework  that  is  developed 

•  Ensure  the  architecture  framework  is  integrated  throughout  the  services  to  facilitate  and 
motivate  collaboration  and  information  sharing 

•  Integrate  key  decision  processes  affecting  the  end  state  and  track  progress  through  use  of 
collaborative  tools 

•  Provide  links  between  the  assessment  process  and  the  oversight  process  and  among  program 
milestones,  resource  decisions,  and  architecture  compliance 

Accomplishing  these  steps  in  the  manner  illustrated  in  Figure  8-8  will  yield  a  process  for 
acquiring  distributed,  highly  networked  sensor,  weapon,  combat,  and  support  systems  that  will 
be  designed  to  deliver  the  critical  integration  and  interoperability  necessary  to  meet  mission 
objectives. 
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When  Does  FoS  Interoperability  Present  Performance  and  Cost-Effectiveness  Benefits? 

The  previous  section  discussed  the  need  for  an  acquisition  process  that  focuses  on  delivery  of 
mission  capability  from  interoperable  FoSs,  but  it  is  important  to  note  that  not  all  operational 
concepts  benefit  from  system  interoperability.  It  is  not  always  feasible  or  cost  effective  to  force 
system  interoperability  into  an  FoS.  Interoperability  has  been  shown  to  be  a  force  multiplier  in 
cases  where  systems  already  offer  inherent  mission  capability.  In  cases  where  no  inherent 
capability  exists,  however,  making  systems  interoperable  may  simply  result  in  a  more  costly  but 
still  ineffective  system.  Compounding  the  difficulty  of  creating  interoperability  among  existing 
systems  is  the  fact  that  legacy  systems  can  be  poor  candidates  for  inclusion  into  an  interoperable 
FoS.  Problems  associated  with  re-engineering  legacy  systems  to  provide  interoperability  include 
obsolete  technology  that  cannot  be  easily  modified;  complications  caused  by  deploying  multiple 
variations  of  the  same  basic  system;  and  the  impact  of  taking  systems  and  platforms  out  of 
service  while  modifications  are  being  made.  Because  providing  interoperability  may  require 
development  of  costly  solutions,  the  resulting  performance  gains  sought  from  the  interoperation 
of  systems  must  be  significant  in  order  to  justify  the  investment. 

The  Three  Myths  of  Interoperability  and  Integration 

To  distinguish  between  myth  and  reality  in  the  areas  of  interoperability  and  integration,  it  is  first 
necessary  to  clearly  define  the  terminology.  The  DoD  technical  community  frequently  confuses 
the  meanings  of  the  following  terms:  interfaced,  networked,  interoperable,  and  integrated. 
Systems  are  interfaced  if  a  communications  bridge  has  been  established  across  a  boundary 
between  two  systems.  While  an  interface  is  necessary  for  systems  integration,  it  is  not  a 
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sufficient  means  for  realizing  the  full  performance  potential  of  an  FoS.  If  an  interface  has  been 
established  between  the  systems  and  a  network  structure,  the  systems  are  considered  to  be 
networked.  Identifying  systems  as  networked  does  not  imply  that  the  systems  are  either 
interoperable  or  integrated.  Systems  are  described  as  interoperable  when  they  can  function 
together  within  an  FoS,  but  systems  are  only  deseribed  as  integrated  if  they  can  guarantee 
accurate  and  timely  transfer  of  necessary  data  between  systems  within  an  FoS.  A  distinction 
must  be  drawn  between  a  system  that  has  been  interfaced  into  an  FoS  and  one  that  has  been 
integrated  into  an  FoS.  They  can  both  provide  interoperability,  meaning  they  can  function  within 
the  FoS,  but  the  performance  capabilities  of  the  integrated  system  are  potentially  far  greater  than 
those  provided  by  the  interfaced  system. 

There  are  at  least  three  myths  associated  with  integration  and  interoperability.  The  first  is  that 
distributed  functionality  always  provides  increased  performance,  cost  effectiveness,  and 
redundancy.  The  seeond  is  that  interoperability  equates  to  foree  multiplieation.  The  third  is  that 
integration  of  multiple  systems  can  somehow  forge  a  capability  where  none  existed  before.  Each 
of  these  myths  is  discussed  in  the  following  paragraphs. 

Myth  1  is  the  fallacy  that  distributed  functionality  always  provides  increased  performance,  cost 
effectiveness,  and  redundaney.  Admiral  Art  Cembrowsky,  U.S.  Navy  (retired),  was  one  of  the 
first  to  debunk  this  mjdh.  His  argument  revolved  around  the  critical  difference  between  platform 
networking  and  platform  integration.  He  noted  that  a  group  of  networked  platforms  could 
continue  operating  with  full  functionality  even  if  they  were  separated  from  the  network,  although 
their  performance  would  laek  the  foree  multiplier  effects  of  being  conneeted.  He  eautioned 
against  dependence  on  integrated  functions  distributed  across  multiple  platforms  because  the 
distributed  funetions  resident  on  a  single  platform  and  distributed  via  the  network  would  be 
unavailable  to  the  force  as  a  whole  if  that  one  platform  was  separated  from  the  network.  To  state 
the  problem  simply,  suppose  each  of  three  platforms  in  a  network  had  sensors,  weapons,  and  a 
command  and  control  system.  These  platforms  could  be  networked  and  operate  together, 
providing  a  foree  multiplier.  If,  however,  one  platform  provided  sensor  funetionality,  the  second 
provided  command  and  control  functionality,  and  the  third  provided  weapon  functionality  and 
these  capabilities  were  available  to  all  platforms  via  integration,  it  would  be  devastating  to  the 
group  if  any  of  the  three  were  destroyed  or  otherwise  separated  from  the  network.  In  Admiral 
Cembrowsky’s  view,  distributing  funetions  over  the  network  was  sub-optimal  beeause  it 
deprived  the  platforms  of  the  ability  to  operate  with  full  autonomy. 

Distributed  functionality  can  have  benefits,  but  total  distribution,  as  described  in  the  previous 
paragraph  and  as  shown  in  Figure  8-9,  designs  multiple  single  points  of  failure  into  the  FoS.  This 
is  an  important  concept  to  understand,  especially  because  DoD  is  currently  attempting  to  move 
away  from  large,  eapital-intensive  platforms  that  provide  autonomous  eapabilities.  Instead,  DoD 
is  moving  toward  acquisition  of  platforms  with  less  inherent  functionality  that  will  have  to  be 
present  in  greater  numbers  to  avoid  single  points  of  failure.  Referring  back  to  the  example 
provided  in  the  previous  paragraph,  DoD  would  require  multiple  land-based,  ship-based,  and  air- 
based  systems  to  provide  redundancy  and  remove  the  single  points  of  failure  posed  by  the  use  of 
integrated  capabilities  resident  on  distributed  platforms. 
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Distributed  Functionaiity 


All  platforms  capable  of  tracking  and 
engaging  threat.  Attack  on  airborne  system 
does  not  negate  capability  of  ship-based  and 
land-based  systems 


Airborne  system  provides  command  and 
control,  ship-based  platform  provides 
tracking,  and  land-based  platform  engages 


Figure  8-9.  Redundant  Functionality  versus  Totally  Distributed  Functionality 


Myth  2  is  the  assumption  that  interoperability  equates  to  force  multiplication.  Force 
multiplication  will  not  be  achieved  through  interoperability  if  threats  attack  in  sectors.  As  shown 
in  Figure  8-10,  a  platform-centric  architecture  is  completely  adequate  as  long  as  threats  remain  in 
a  sectored  battlespace.  When  threats  amass  in  one  sector,  however,  significant  force 
multiplication  is  gained  through  integration.  The  fact  is  that  the  force  multiplication  advantages 
of  interoperability  are  dependent  upon  the  scenario  and  the  threat,  and  the  probable  types  of 
scenarios  and  threats  platforms  may  face  must  be  considered  in  determining  the  significance  of 
the  advantage  that  would  be  gained  through  achievement  of  interoperability. 


Myth  3  is  the  incorrect  assumption  that  integrating  systems  can  provide  a  capability  where  none 
existed  before.  If  the  inherent  capability  to  perform  a  function  does  not  exist  in  an  FoS,  then 
integration  will  not  forge  that  capability.  For  example,  a  group  of  distributed  airborne 
surveillance  sensors,  each  with  the  capability  to  detect  a  certain  threat  at  200km,  may  have 
surveillance  coverage  similar  to  what  is  represented  in  Figure  8-11.  Netting  these  sensors 
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together  will  not  enable  them  to  detect  targets  that  they  individually  could  not  detect.  As 
indicated  by  the  red  line,  the  combined  surveillance  coverage  provided  by  the  networked  sensors 
will  increase  to  the  sum  of  the  parts,  allowing  a  larger  area  to  be  surveyed  for  targets  the 
individual  systems  can  detect.  But  if  a  target  is  below  an  individual  sensor’s  detection  threshold, 
it  will  remain  below  the  networked  sensors’  detection  threshold.  Put  another  way,  integration  and 
interoperability  do  not  allow  an  FoS  or  an  SoS  to  violate  the  laws  of  physics. 


Figure  8-11.  Effect  of  Sensor  Netting  on  Increased  Surveillance  Coverage 


It  should  be  noted,  however,  that  integration  and  interoperability  can  allow  improvement  in 
information  utility.  For  example,  in  Figure  8-11,  the  individual  surveillance  coverages  limit  the 
tracking  capabilities  (ranges)  of  the  individual  sensors.  But  consider  the  fact  that  tracking  is  an 
aggregation  of  detection  data.  Therefore,  if  the  individual  sensor’s  track  data  can  be  accurately 
geospatially  registered  and  time-aligned,  the  family  of  sensors  will  then  enjoy  a  greater 
(aggregate)  track  range  than  the  individual  sensors. 

Legacy  Systems:  Not  Necessarily  Suitable  Candidates  for  FoS  Engineering 

In  assessing  the  potential  returns  to  be  gained  in  implementing  FoS  interoperability,  it  is 
necessary  to  consider  if  and  how  legacy  systems  can  be  integrated  into  the  FoS.  The  challenges 
associated  with  integrating  legacy  systems  into  an  FoS  are  numerous.  First,  these  systems 
frequently  employ  outdated  technology  that  is  difficult  or  impossible  to  modify.  Legacy  systems, 
especially  those  fielded  before  1990,  are  designed  with  specialized  computer  hardware  and 
programming  techniques  that  are  primitive  by  today’s  standards.  Interfacing  these  systems 
directly  to  current  or  emerging  hardware  can  be  extremely  challenging.  Legacy  system  data  may 
not  be  available  at  an  established  input/output  port,  a  fact  that  will  require  internal  modification 
of  the  system  without  any  resultant  negative  effects  on  system  performance  or  real-time 
operations.  Additional  problems  will  arise  if  hardware  schematics  are  incomplete  and  the  system 
designers  are  retired  or  otherwise  unavailable,  a  situation  that  will  require  reverse  engineering  of 
the  hardware  component.  Integration  of  software  from  legacy  systems  also  presents  difficulties. 
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The  programming  techniques  of  previous  decades  do  not  easily  lend  themselves  to  modification. 
Some  programs  are  written  in  what  are  now  obsolete  programming  languages  (e.g.,  CS/2)  or 
assembly  languages  for  processors  that  have  been  discontinued  for  years.  The  expertise  to 
modify  these  programs  may  no  longer  exist,  and  even  if  it  does,  integrating  software  written  in 
these  languages  presents  risks  to  system  stability  and  real-time  performance. 

A  second  issue  associated  with  integrating  legacy  systems  into  integrated  FoSs  is  the  existence  of 
multiple  versions  of  similar  legacy  systems.  On  many  large-capital  DoD  legacy  systems,  a  spiral 
development  process  is  used  to  support  continuous  development  of  more  and  more  capable 
versions  of  the  same  system.  While  this  approach  has  advantages  in  providing  enhanced 
capability  over  time,  it  also  yields  numerous  versions  of  the  same  system.  The  Aegis  Computer 
Program  provides  an  example  of  a  system  that  has  evolved  through  numerous  iterations.  In  2002, 
there  were  at  least  five  operationally  deployed  major  baselines  as  well  as  many  other  minor 
baselines  of  this  system.  This  situation  can  present  serious  challenges  for  the  integration  of  a 
legacy  system  into  an  integrated  FoS  because  the  integration  effort  is  not  focused  on  a  single 
system  but  rather  the  integration  of  numerous  separate  legacy  systems.  Budgets  and  schedules 
for  integrating  legacy  systems  into  FoSs  must  reflect  the  possibility  that  there  may  be  multiple 
versions  of  the  legacy  system. 

The  third  hurdle  associated  with  the  FoS  integration  of  legacy  systems  is  scheduling  system 
modifications  into  the  operational  deployment  schedules  of  the  legacy  system.  Since  many 
platforms  and  systems  are  routinely  scheduled  for  maintenance  and  upgrade  intervals,  this  issue 
is  frequently  resolvable;  however,  additional  scheduling  conflicts  can  arise  if  components 
requiring  specialized  testing  and  qualifications  (e.g.,  live-fire  missile  exercises)  are  modified. 
Again,  these  issues  must  be  considered  in  assessing  the  viability  of  integrating  legacy  systems 
into  an  FoS. 

A  final  consideration  associated  with  legacy  system  integration  into  an  FoS  is  the  calendar  time 
required  to  modify  each  particular  system.  The  modification  period  required  to  support 
integration  can  span  several  years.  During  that  time,  newer  versions  of  a  particular  system  may 
be  placed  in  service,  and  plans  may  be  made  to  retire  older  platforms  and  systems.  Accordingly, 
it  is  critical  to  assess  the  calendar  time  required  to  deploy  a  modified  legacy  system  in  relation  to 
both  the  expense  of  the  modification  and  the  amount  of  time  remaining  in  the  system’s  service 
life. 

The  Cost  of  Integration  and  the  Need  for  an  Offsetting  Payoff 

Each  paragraphs  of  this  section  has  emphasized  the  need  for  careful  consideration  of  the 
anticipated  advantages  to  be  gained  through  integration  in  relation  to  the  costs  and  challenges 
associated  with  accomplishing  that  objective.  As  one  might  expect,  integrating  systems  is  not 
inexpensive.  For  an  integration  effort  to  be  cost-effective,  it  must  deliver  an  increase  in 
capability  that  is  less  expensive  to  achieve  through  integration  than  through  design  of  new 
systems  or  procurement  of  multiple  copies  of  existing  systems.  Figure  8-12,  for  example,  shows 
that  it  may  be  less  expensive  to  develop  a  longer-range  missile  to  meet  longer  range  engagement 
requirements  than  it  would  be  to  integrate  fire  control  ftinctions  across  multiple  platforms  in 
order  to  accomplish  the  same  objective.  While  it  is  typically  argued  that  creating  integration  and 
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interoperability  among  existing  systems  is  more  eost-effeetive  than  new  development,  this  is  not 
always  true,  and  all  alternatives  should  he  investigated  before  a  commitment  to  FoS  integration 
is  made. 


Costs  associated  with  integration  include  necessary  expenditures  in  the  areas  of  engineering,  test 
and  evaluation,  and  infrastructure.  Engineering  costs  include  research  and  development,  design, 
fabrication,  and  installation.  Systems  integration  efforts  require  changes  to  system  specifications, 
and  these  changes  must  he  accomplished  using  a  comprehensive  and  frequently  expensive 
process  that  begins  with  research  and  development  to  assess  preliminary  design  alternatives. 
Once  a  preliminary  design  is  chosen,  further  expenditures  may  be  required  to  fund  completion  of 
the  necessary  drawings  or  schematics  for  fabrication  of  any  required  parts  or  modifications.  Once 
the  drawings  are  developed,  more  costs  will  be  incurred  in  installing  fabricated  parts  and 
completing  any  system  modifications.  To  ensure  quality  control  and  configuration  management, 
all  of  these  engineering  design  steps  must  be  accomplished  even  for  simple  modifications,  and 
they  are  generally  both  expensive  and  time-consuming  to  complete. 

While  engineering  can  be  expensive,  these  costs  are  accompanied  by  the  cost  of  test  and 
evaluation.  After  fabrication  and  installation,  the  modification  must  be  tested.  If  the  modification 
is  designed  to  make  systems  on  multiple  platforms  interoperable,  test  and  evaluation  costs  may 
be  significantly  higher  than  those  that  would  be  incurred  in  testing  capabilities  of  systems  on  a 
single  platform  simply  because  more  manpower  and  equipment  will  be  required.  For  some 
modifications,  test  ranges  must  be  scheduled;  additionally,  if  weapons  fire  is  involved,  test 
targets  may  have  to  be  procured.  Obviously,  the  cost  for  testing  and  evaluating  modifications  can 
quickly  escalate.  For  example,  test  and  evaluation  of  baseline  upgrades  to  the  Aegis  Combat 
System  Computer  Program  can  cost  tens  of  millions  of  dollars. 

Adding  to  engineering  and  testing  costs  are  those  costs  associated  with  infrastructure  to  support 
the  integration  effort.  Examples  of  infrastructure  costs  include  the  expense  of  increasing 
bandwidth  in  an  existing  communication  system  and  the  expenditures  necessary  to  gain  more 
precise  or  detailed  data  from  existing  support  systems  such  as  navigation  or  meteorology. 
Infrastructure  costs  are  driven  by  the  fact  that  making  systems  interoperable  involves  exponential 
increases  in  the  number  of  systems  accessing  communications  and  the  amount  of  data  being 
transferred.  For  example,  it  is  estimated  that  by  2015,  5,000  U.S.  systems  will  be  Link- 16 
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capable.  Without  a  significant  infrastructure  investment  in  increasing  bandwidth,  selection  as 
well  as  priority  criteria  may  have  to  be  applied  to  data  messages  on  the  link.  Further,  if  large 
numbers  of  systems  rely  on  Link- 16  to  interoperate,  it  may  not  be  reliable.  Another  example  of 
the  costs  associated  with  providing  infrastructure  to  support  interoperability  is  provided  by  the 
Navy’s  work  in  developing  a  CEC.  Beeause  the  amount  of  data  envisioned  to  be  earried  by  the 
CEC  was  too  great  for  any  existing  data  link,  the  CEC  system  was  designed  with  an  embedded 
dedicated  data  link.  The  suceess  of  the  CEC  system  has  outpaeed  the  ability  of  the  dedicated  link 
to  transfer  data,  and  the  CEC  program  is  now  planning  a  Block  2  variant  that  will  allow  more 
users  on  the  network  in  the  available  bandwidth.  Other  infrastructure  eosts,  including  costs  for 
improving  the  capabilities  of  support  systems,  are  sometimes  overlooked  in  tallying  the  costs 
associated  with  providing  interoperability.  Navigation  systems  provide  a  good  example.  It  has 
become  apparent  that  the  accuracy  of  platform  system  navigation  has  a  profound  effect  on  the 
accurate  fusing  of  traek  data  from  sensors  on  multiple  platforms.  In  fact,  the  level  of  navigation 
accuracy  has  sometimes  been  identified  as  the  limiting  factor  in  developing  a  fiised  track  picture. 
Upgrading  navigation  systems  eould  therefore  be  viewed  as  a  hidden  cost  of  providing 
interoperability. 

The  bottom  line,  then,  is  the  bottom  line.  It  is  critical  to  assess  all  the  costs  associated  with  an 
integration  effort  to  determine  return  on  investment  prior  to  eommitting  to  the  effort. 

How  Can  Architectures  be  Applied  to  Systems  Development? 

The  previous  seetions  of  this  ehapter  addressed  the  history,  advantages,  and  limitations 
associated  with  using  architectures  to  support  acquisition  decision-making.  This  section 
introduces  a  more  basie  application  of  architectures:  doeumentation  of  a  blueprint  for  FoS 
development.  Just  as  a  building  architect  develops  blueprints  so  that  individual  contractors  can 
determine  the  seope  and  requirements  of  their  jobs,  the  systems  arehitect  develops  blueprints  in 
accordance  with  the  DOD  Architecture  Framework  so  that  individual  program  managers  can 
determine  the  seope  and  requirements  of  their  systems.  These  blueprints  -  referred  to  within  this 
book  as  architecture  views  -  serve  to  bring  all  stakeholders  a  common  vision  of  the  solution. 
They  provide  a  framework  for  conducting  inter-program  system  engineering  diseussions  and 
tradeoff  analyses,  and  perhaps  most  importantly,  they  deliver  a  framework  for  arbitration  of 
issues  between  various  program  managers  developing  or  maintaining  the  FoS.  They  ean  and 
should  be  a  critical  tool  in  creating  a  new  process  for  conducting  systems  development  and 
acquisition  that  focuses  on  delivering  the  interoperability  needed  to  support  eoneepts  like 
Network  Centric  Warfare. 

The  Challenge  of  Gaining  Common  Understanding  of  Requirements 

The  DoD  series  5000  instructions  state  that  for  each  milestone  review  on  their  respective 
programs,  program  managers  must  develop  arehitectures  that  meet  the  Architeeture  Framework 
Standard.  The  architecture  that  a  single  program  manager  develops  and  submits  to  the  Defense 
Aequisition  Board  should  not  be  an  independently  developed  entity;  rather,  it  should  be 
consistent  with  architectures  developed  and  submitted  for  other  systems  within  the  FoS.  At  the 
time  of  this  writing,  however,  the  consistency  necessary  in  arehitectures  for  systems  within  the 
FoS  has  not  been  achieved.  Typically,  program  managers  are  independently  developing 
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architectures  to  satisfy  the  DoD  requirement.  This  independent  development  yields  architectures 
that  cannot  provide  a  common  understanding  of  requirements,  including  inter-program 
interoperability.  Figure  8-13  demonstrates  how  a  documented  and  consistent  architecture  can 
address  these  problems. 


Figure  8-13.  Facilitation  of  Inter-program  Communications  by  a  Documented  Architecture 


The  FoS  Architecture:  A  Blueprint  for  FoS  Development 

As  discussed  in  previous  chapters,  the  architecture  embodies  a  program’s  operational  concept 
through  the  operational  views  and  its  functional  and  physical  concepts  through  the  system  and 
technical  views.  When  combined  with  Capstone  and  FoS  requirements,  the  architecture  will 
provide  all  program  managers  with  the  necessary  information  to  begin  systems  development. 
The  relationships  of  these  documents  are  illustrated  in  Figure  8-14  and  explained  below  using  a 
hypothetical  example  of  an  FoS  being  developed  for  ballistic  missile  defense. 


Figure  8-14.  Relationship  of  Architecture  and  Requirements  Documents 
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Operational  views  provide  the  overall  concept  of  operations.  For  this  example,  operational  views 
will  provide  answers  to  the  following  questions: 

•  What  platforms  will  be  used? 

•  What  are  the  expected  threats? 

•  What  are  the  required  engagement  zones? 

•  How  will  different  platforms  interact  to  perform  the  mission? 

•  What  activities  must  occur  to  perform  the  mission? 

•  How  will  command  be  structured? 

For  the  hypothetical  Ballistic  Missile  Defense  System  (BMDS),  the  operational  concept  may  be 
ship-based;  must  defeat  certain  types  of  Theater  Ballistic  Missiles  (TBMs)  within  a  defined 
number  of  kilometers  inland;  and  must  make  space-based  cueing  available  (though  it  will  not 
always  be  available).  Additionally,  under  the  defined  operational  concept,  authorization  for 
engagement  may  be  delegated  to  each  ship  or  centralized. 

The  Capstone  Requirements  Document  formalizes  many  of  the  concepts  and  performance 
figures  identified  in  the  operational  views  and  provides  key  performance  metrics  for  use  in 
evaluating  the  FoS.  For  the  BMDS,  requirements  might  be  placed  on  defended  area,  raid  size, 
threat  capabilities,  reliability,  and  training.  The  operational  views  and  the  Capstone 
Requirements  Document  can  be  combined  and  collectively  reviewed  since  they  contain  much  of 
the  same  data.  The  U.S.  Space  Command  (USSPACECOM)  did  this  effectively  in  developing 
the  NORAD/USSPACECOM  Warfighting  Support  Systems  procurement. 

System  Views  allow  activities  defined  in  the  operational  views  to  be  traced  to  specific  functions, 
systems,  and  platforms.  They  also  identify  the  required  data  that  must  be  transferred  among 
systems  to  perform  the  mission.  For  the  BMDS  example,  a  detect  activity  may  be  mapped  to  the 
AN/SPY- 1  Radar;  an  engage  activity  may  be  mapped  to  the  Aegis  Command  and  Decision 
System  and  the  Aegis  Weapon  Control  System;  and  an  intercept  activity  may  be  mapped  to  the 
Standard  Missile.  Interface  diagrams  between  these  systems  illustrate  required  connectivity,  data 
content,  data  accuracy,  and  timeliness.  Again  referring  to  the  BMDS  example,  missile  target 
acquisition  data  may  be  identified  as  coming  from  the  AN/SPY- 1  Radar  to  the  Standard  Missile 
via  either  3-,  6-,  or  9-state  track  updates  and  adhering  to  a  minimum  accuracy  requirement 
during  an  interval  defined  before  intercept. 

Technical  Views  provide  the  protocols  to  be  used  to  support  data  transfer.  In  the  BMDS 
example,  if  Link- 16  were  used  to  pass  track  data  among  ships,  the  format  of  the  message 
structure  would  be  provided  in  the  technical  views.  Alternatively,  if  the  Internet  were  used  to 
pass  information,  file  transfer  protocols  and  security  encryption  would  be  defined. 

The  System  Requirements  Document  allocates  the  FoS  performance  requirements  identified  in 
the  Capstone  Requirements  Document  to  the  systems  defined  in  the  system  views.  For  the 
hypothetical  BMDS,  the  system  views  mapped  detection  activity  to  the  AN/SPY- 1  Radar  and 
intercept  activity  to  the  Standard  Missile  and  defined  the  necessary  data  that  must  flow  between 
them  to  meet  operational  concept  requirements.  The  System  Requirements  Document  places 
performance  figures  and  metrics  on  these  systems  that  will  enable  achievement  of  the  Capstone 
Requirements.  For  the  BMDS,  defended  area  requirements  may  be  mapped  into  detection  range 
requirements  for  the  AN/SPY- 1  Radar  and  fly-out  time  requirements  for  the  Standard  Missile. 
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There  is  no  reason  that  the  data  in  the  Systems  Requirement  Doeument  eould  not  be  made  part  of 
the  system  architecture,  but  adding  this  data  to  the  systems  views  is  not  required  by  the 
architecture  framework. 

Applying  the  Blueprint 

Once  the  blueprint  for  an  FoS  is  developed,  it  must  be  applied  to  each  system  within  the  FoS  in 
order  to  achieve  the  architectural  consistency  that  is  necessary  for  interoperability.  The 
Architecture  Framework  products,  which  include  all  the  data  and  requirements  for  the 
overarching  FoS,  would  be  given  to  each  program  responsible  for  developing  a  system  within  the 
FoS.  At  that  point,  each  program  would  develop  additional  requirements  documents  or  system 
specification  documents  that  are  traceable  back  to  the  FoS  architecture.  Capstone  requirements, 
and  FoS  requirements.  In  this  manner,  systems  development  would  be  conducted  with  a  common 
set  of  requirements  for  the  entire  FoS.  Additionally,  if  for  any  reason  these  common 
requirements  could  not  be  met  by  a  specific  program,  the  architecture  would  provide  the 
framework  for  adjudicating  and  resolving  conflicts  early  in  the  design  process. 

It  is  very  likely  that  inter-systems  engineering  tradeoffs  will  become  a  staple  made  possible  by 
the  architecture.  Using  the  BMDS  example,  assume  the  interceptor  could  not  achieve  the 
required  average  velocity.  An  inter-system  engineering  tradeoff  could  be  made  to  require  an 
earlier  launch  in  order  to  maintain  the  operational  concept.  Accepting  this  tradeoff  would  require 
either  earlier  detection  or  faster  development  of  a  fire  control  solution  due  to  the  reduced  time 
available.  These  alternatives,  along  with  the  alternative  of  re-engineering  the  interceptor,  must 
be  evaluated  from  both  technical  and  financial  perspectives  by  the  board  responsible  for 
maintaining  the  integrity  of  the  architecture.  Once  a  solution  is  determined,  the  architecture 
would  be  adjusted  and  re-issued  to  the  programs.  By  addressing  challenges  from  an  inter-systems 
engineering  perspective,  individual  programs  can  avoid  trying  to  fix  insurmountable  problems 
independently  when  a  technically  feasible,  less  costly  option  may  be  available  through  an  inter¬ 
system  engineering  approach. 

Using  the  architecture  as  a  blueprint  for  FoS  development  provide  numerous  advantages  from  an 
interoperability  perspective.  First,  the  architecture  lets  each  program  know  what  data  it  must 
provide  and  what  data  it  can  expect.  Second,  if  the  data  will  not  be  available  or  additional 
funding  is  required  to  develop  the  interface,  the  architecture  provides  a  structure  for  raising  and 
resolving  these  issues.  Finally,  if  a  program  manager  determines  that  a  requirement  cannot  be 
met  for  any  reason,  the  architecture  provides  a  framework  for  adjudicating  and  resolving  this 
conflict.  This  process  is  illustrated  in  Figure  8-15.  The  smooth  process  depicted  in  this 
illustration  brings  us  back  to  the  DoD  5000  requirement  for  each  program  to  provide  an 
architecture  at  its  milestone  reviews.  The  development  and  promulgation  of  FoS  architectures 
does  ease  the  burden  presented  by  requiring  individual  programs  to  develop  this  data 
independently,  and  it  offers  the  opportunity  for  architectures  to  be  used  up  front  to  build 
interoperability  into  FoSs.  Still,  the  architecture  and  any  associated  problems  need  to  be  defined 
earlier  than  an  initial  milestone  review,  and  regular  reviews  of  the  architecture  need  to  occur 
more  frequently  than  milestone  reviews.  Unfortunately,  this  need  has  not  been  addressed  in  the 
DoD  acquisition  instructions. 
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Figure  8-15.  Using  the  Architecture  to  Augment  Requirements  in  FoS  Development 


Summary 


Although  the  DoD  Architecture  Framework  products  were  not  originally  designed  to  analyze 
FoSs  derived  from  programs  of  record  to  develop  acquisition  strategies,  they  can  be  and  have 
been  adapted  to  support  this  function.  In  fact,  these  modified  architecture  framework  products 
have  been  used  successfully  to  support  various  DoD  projects,  as  described  in  the  case  studies  in 
Part  II  of  this  book.  Continuing  to  build  and  use  this  new  process  will  require  guidance  and  buy- 
in  from  senior  leadership  and  throughout  the  acquisition,  engineering,  and  operational  ranks.  The 
initial  time  and  cost  required  to  continue  development  of  the  framework  for  architectural 
assessments  will  not  be  insignificant.  Once  the  baseline  architecture  is  established,  however,  it 
will  only  require  periodic  updates  and  modifications  as  requirements  change.  Further,  the 
alternative  -  continuous  investment  in  system  duplications  and  the  failure  to  fill  gaps  in  mission 
capability  -  is  simply  unacceptable.  Even  so,  it  must  be  remembered  that  designing  and 
developing  interoperable  systems  is  not  inexpensive,  nor  is  it  always  the  smartest  path  to  take. 
Interoperable  systems  do  not  necessarily  provide  better  performance;  further,  performance 
enhancements  can  only  be  realized  if  the  systems  within  the  FoS  have  an  inherent  capability  to 
perform  mission  requirements.  A  clearly  defined  payoff  should  be  established  before  deciding  to 
integrate  systems  that  initially  appear  to  be  suitable  candidates  for  inclusion  in  an  FoS.  Finally,  it 
is  clear  that  the  architecture.  Capstone  Requirements,  and  FoS  requirements  provide  all  that  is 
necessary  to  begin  documentation  of  a  blueprint  for  FoS  development.  After  the  architecture  and 
requirements  are  distributed,  each  program  should  understand  its  expected  functional, 
performance,  and  interoperability  requirements.  The  use  of  architectures  as  blueprints  for 
developing  FoSs  enables  programs  to  avoid  at  least  some  of  the  hidden  costs  and  technical 
roadblocks  associated  with  FoS  development.  This  process  provides  one  method  for  addressing 
the  expanding  interoperability  problems  that  are  affecting  the  military  services. 
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CHAPTER  9^ 

ARCHITECTURE  DATA  MANAGEMENT 


Purpose 

Chapter  2  introduced  the  Architecture  Framework  products,  and  Chapters  3  through  7  provided 
case  studies  illustrating  how  they  can  be  used  to  support  the  architecture  assessments  necessary 
to  define  MCPs.  The  analyses  described  in  the  case  study  chapters  depend  upon  significant 
amounts  of  architecture  data.  This  chapter  addresses  the  methods  for  capturing  the  data  products 
for  systems  engineering  and  acquisition  planning,  and  it  describes  how  MCP  data  can  be 
managed  and  synchronized.  The  chapter  also  describes  some  of  the  tools  for  quantitative 
analyses  that  can  be  done  with  architecture  data.  The  chapter  concludes  with  an  example  of  CED 
data  management. 

Data  Integrity 

In  order  for  MCP  analysis  results  to  be  accurate,  the  data  used  to  conduct  the  analysis  must  have 
integrity.  Data  integrity  will  be  most  affected  by  the  following  two  principal  factors: 

•  Accuracy  of  architecture  data 

•  Consistency  among  architecture  data  values  and  with  data  values  within  and  beyond  a  single 
service  (e.g.,  the  Department  of  the  Navy) 

This  chapter  discusses  the  second  of  these  two  aspects  of  data  integrity.  The  concept  of 
consistency  in  data  values  may  at  first  appear  very  simple,  but  it  becomes  challenging  in  large- 
scale  assessments  like  MCP  analyses  because  they  involve  so  much  complex  and  highly 
interrelated  data.  Without  rigorous  data  management  processes,  maintaining  data  value 
consistency  can  quickly  become  unmanageable.  Table  9-1  illustrates  this  effect,  showing  that 
even  for  what  most  would  consider  small  architectures,  large  numbers  of  architecture  artifacts 
result.  Without  effective  data  management,  the  large  number  of  architecture  artifacts  can  lead  to 
consistency  problems,  and  these  problems  can  have  significant  consequences.  Accordingly,  any 
architecture  project  that  plans  on  using  quantitative  analyses  of  the  type  necessary  for  MCP 
assessments  must  allocate  some  rigor  to  the  management  of  collected  and  developed  data. 

Quantitative  Analysis  with  Architecture  Data 

Usually,  it  is  not  obvious  that  a  proposed  or  planned  architecture  is  the  best  solution  for  an 
enterprise.  A  variety  of  factors  affect  an  architecture  choice  or  plan.  Table  9-2  presents  examples 
of  varied  enterprise  requirements  and  issues  along  with  potential  enterprise  measures  of  merit. 


f  This  work  is  the  collaboration  of  Brian  Wilczynski,  the  DON  CIO  Enterprise  Architect,  and  Dr.  Harrold  Crisp, 
RDA  CHENG  Director  of  the  Naval  Collaborative  Engineering  Environment. 
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Table  9-1 


Expected  Numbers  of  Artifacts  Based  on  Number  of  Taxonomic  Objects  Addressed 


Taxonomy  Class/Architecture  Size 

Small 

Mid 

Large 

Operational  Nodes 

10 

100 

500 

Operational  Activities 

50 

500 

2,500 

Information  Elements 

100 

1,000 

2,500 

Events  &  Triggers 

5 

50 

200 

System  Eunctions 

25 

250 

1,000 

Systems 

10 

100 

500 

Physical  Nodes 

5 

50 

250 

Performance  Characteristics 

25 

250 

750 

Technical  Standards 

25 

25 

500 

Technologies 

5 

25 

150 

Approximate  Number  of  Architecture  Artifacts 

6,000 

60,000 

250,000 

Table  9-2 


Enterprise 

Requirement/Issue 

Associated  Measures  of  Merit 

Info  Requirements 
Satisfaction 

•  Automated  info  refinement  •  Info  delivery/availability 

Interoperability  - 
Communications 

•  Layer  0  -  Phys.  media  compatibility  •  Layer  4  -  Trans,  layer  compatibility 

•  Layer  1  -  Phys.  layer  compatibility  •  Layer  5  -  Session  layer  compatibility 

•  Layer  2  -  Datahnk  layer  compatibihty  •  Layer  6  -  Present,  layer  compatibihty 

•  Layer  3  -  Network  layer  compatibihty  •  Layer  7  -  App.  layer  compatibility 

Interoperability  - 
Data 

•  Access  •  Assimilation  and  synchronization 

•  Interpretation 

Interoperability  - 
Eunctional 

•  C4ISR  and  weapons  systems  •  Common  support  services 

•  Enterprise  services  •  Business  operations 

•  Enterprise  applications  services 

Security  - 

Communications/ 

Network 

•  Access  control  •  Non-repudiation  producer 

•  Availability  •  Non-repudiation  consumer 

•  Confidentiality  •  Protection  (type,  name,  duration,  date) 

•  Dissemination  control  •  Classification 

•  Criticality  •  Classification  caveat 

•  Integrity  •  Releasability 

Manning  Impact 

•  Business  process  streamlining  •  Automation  reduction  assessment 

Logistics  Impact 

•  Maintenance  and  sparing 

Capacity  Planning 

•  Communications  •  Growth  capacity 

•  Lor  a  particular  ship,  exercise,  •  Pierside 

weapon  system,  LY,  location  •  Commercial  trade-off  with  mil 

•  Commercial  SATCOM  leasing  rqmts.  SATCOM 

•  End-user  equipment/Apps/SW  •  Tech  refresh  planning 

Budget  and  Cost 
Analysis 

•  Cost  of  an  alternative  for  any  time  •  Capabilities  and  requirements  impact 

period  analysis 

•  Budget/cost  by  system,  platform,  etc.  •  WBS  analysis 

•  Budget/cost  by  WBS  •  Out-year  budget 

•  Accumulated  cost  per  acquiring  org  •  Budget  controls 

•  Variance  analysis 
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Figure  9-1  presents  some  general  relations  between  tools  and  architecture  data  products.  As  the 
engineer  or  analyst  moves  between  the  different  levels  of  analysis,  consistency  between  data 
products  must  be  achieved  in  order  to  apply  various  Modeling  and  Simulation  (M&S)  programs. 
The  DoD  has  invested  significant  resources  in  a  variety  of  M&S  programs.  The  data  meta  model 
to  support  M&S  programs  is  the  C4ISR  Core  Architecture  Data  Model  (CADM).  It  was 
originally  developed  not  only  to  model  the  data  of  Architecture  Framework  data  products  but 
also  to  model  data  for  M&S  programs  designed  to  perform  architectural  and  interoperability 
analyses.  The  advantage  of  using  CADM  structures  for  developing  and  maintaining  measures 
data  is  that  M&S,  analysis,  and  assessment  tools  developed  or  modified  to  compute  the  measures 
based  on  CADM  data  are  standardized.  This  means  that  multiple  M&S,  analysis,  and  assessment 
tools  can  use  the  same  data  sets  (providing  significant  data  reuse)  and  that,  over  time,  a  set  of 
M&S,  analysis,  and  assessment  tools  can  evolve  to  provide  a  fuller  set  of  measures  needed  for 
decision  support. 


To  illustrate  this  point,  consider  the  example  of  Network  Warfare  Simulation  (NETWARS), 
shown  in  Figure  9-1.  NETWARS  is  a  Government  Off-The-Shelf/Commercial  Off-The-Shelf 
(GOTS/COTS)  tool  that  models  communications  throughput  using  CADM-based  architecture 
data.  NETWARS  uses  lER  attributes  to  assess  a  variety  of  parameters  (e.g.,  information  element 
size,  frequency,  timeliness,  security,  required  format)  along  with  operational  node  to  physical 
node  mappings  to  estimate  bandwidth  requirements  at  physical  nodes,  predict  throughput 
bottlenecks,  and  address  other  communications  measures. 


Dynamic 

Assessments  ^  i  k 

JWARS 


NETWARS 


Physics 

Models 


Sorties 

Tasking 

Resources 


Commander  Logic 
C4ISR  Architecture 
Operational  Scenario 


Platform/System 
Characteristics 
and  Performance 


Component 

Level 

Performance 


static 
Assessments 


Figure  9-1.  Models  Pyramid 
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lER  attributes  at  the  operational,  functional,  and  system  levels,  across  time  periods,  or  within 
“as-is”  and  “to-be”  models  are  not  the  only  CADM  data  elements  that  can  be  used  to  compute 
measures.  Task  and  process-activity  man-levels,  network  architectures,  scenario  information, 
performance  data,  and  technical  standards  like  communication  protocols  can  all  be  input  for 
M&S  and  analysis  tools  for  measures  computation. 

Example  of  Metrics-Based  Architectural  Analysis 

A  study  by  the  OSD  C3I  Decision  Support  Center  (DSC)^^  illustrates  both  a  performance  and 
effectiveness  analysis  of  alternative  architectures  using  architecture  data,  two  levels  of  metrics, 
and  M&S.  In  this  study,  an  information  requirements  model  was  developed  to  answer  the 
question,  “What  are  the  information  needs  of  soldiers  that  might  be  improved  by  alternative 
fusion  architectures?”  or,  put  another  way,  “What’s  a  pound  of  fusion  worth?”  Thousands  of 
authoritative  information  requirements  were  analyzed  and  categorized  based  on  required 
information  type  and  quality.  Table  9-3  provides  a  high-level  categorization  of  the  object  types 
that  pertained  to  these  information  requirements.  Table  9-4  lists  the  information  groups  into 
which  all  information  requirements  could  be  categorized. 


Table  9-3 

Multi-INT  Fusion  Study  Object  Types 


Category 

Types  of  Objects 

Platforms  and  facilities 

Ships,  aircraft,  missiles,  vehicles.  Special  Operations  Forces  (SOF) 
units.  Strategic  Air  Missile  (SAM)  sites,  etc.  from  Company  level  up 
to  Corps  level 

Infrastructure 

Communications  networks,  electrical  networks/grids,  transportation 
networks,  etc. 

Politically-related  items 

National  organization,  intent,  internal  conflicts,  economic  triggers  and 
indicators,  etc. 

Table  9-4 

Multi-INT  Fusion  Study  Information  Categories 


Category 

Types  of  Information  Requirements 

Kinematics 

Location,  velocity,  and  trajectory  (past  and  predicted),  from  detection 
to  accuracy  sufficient  for  Precision  Guided  Munitions  (PGMs) 

Identification 

Broad  type  to  specific  unit  and  with  varying  certainty 

Activity 

General  to  specific  plan  and  with  varying  certainty 

Status 

General  to  specific  and  with  varying  certainty 

Intent 

General  to  specific  and  with  varying  certainty 

The  information  categories  and  qualities  and  the  object  types  to  which  they  pertained  were  used 
to  construct  a  “knowledge  matrix.”  MOPs  were  defined,  along  with  a  method  to  compute  them, 
to  measure  how  much  more  alternative  fusion  architectures,  primarily  oriented  to  Imagery 
Intelligence  (IMINT)  and  Signals  Intelligence  (SIGINT)  national  and  tactical  sensors,  would 
affect  satisfaction  of  information  requirements  for  different  missions.  A  COTS  M&S  tool  was 
used  to  compute  the  knowledge  matrix  satisfaction  depending  upon  the  fusion  algorithm  features 


Using  Architectures  for  Research,  Development,  and  Acquisition 


153 


enabled  in  the  alternative  architeetures.  The  M&S  tool  also  provided  the  fusion  results  to  a 
GOTS  campaign-level  M&S  tool  that  operated  a  full  operational  scenario  and  computed  mission 
outcomes  so  that  both  measures  of  requirements  satisfaction  as  well  as  mission  outcome  could  be 
presented  in  the  analysis  output.  This  study  was  briefed  throughout  the  DoD  and  Intelligence 
communities  and  was  well  received. 

Architecture  Data  Management  Principles 

To  ensure  architecture  data  management  in  terms  of  synchronization  and  consistency,  the 
architecture  must  incorporate,  at  a  minimum,  the  principles  embodied  in  the  following  five  data 
and  architecture  guidelines: 

■  Data  Development  Plan 

■  Common  Architecture  Framework 

■  Common  Data  Structure 

■  Common  Data  Semantics 

■  Data  Synchronization 

The  principles  behind  each  of  these  guidelines  are  described  in  the  following  subparagraphs. 

Data  Development  Plan:  Architecture  Data  Collection/Development  for  Quantitative  Analysis 

While  the  Architecture  Framework  provides  a  structure  for  architecture  data  collection,  it  is 
insufficient  to  develop  and  collect  architecture  data  without  detailed  forethought  of  the 
quantitative  analyses  planned  for  that  data.  For  this  reason,  the  selection  of  the  data  and  products 
to  be  developed  must  be  based  on  the  planned  analysis  rather  than  on  non-analytical  criteria.  An 
analytical  approach  to  architecture  data  development  is  illustrated  in  Figure  9-2. 


Analyses  Required 


Gaps  and  Overlaps  Identification 

Same  or  equivalent  functions,  interfeces  /  information 
capabilities,  performance,  tech  standards,  ... 

Estimate  of  Mission  Impacts  of  System  Shortfalls 

Mission  Information  Needs  Definition 

e.g.,  by  Operational  Role  with  specific  quality  characteristics 

System,  FoS,  SoS  Requirements 

e.g.,  FoS  SRD,  System  Specification 

FoS  /  SoS  Interface  Rqmts. 

e.g..  Interface  Requirements  Document  /  Spec 

1  nte  roperabi  llty  Assessment 

Technical 

Physical  to  Application  Layers 

Protocal  compatibilities,  translation  and  conversion  trade-offs 

Services 

Service  availabilities  and  compatibilities 

Functional 

e.g.,  correlation,  registration,  and  ID  algorithms  and  logic 

FoSZ/SoS  Configuration  Management 

e.g.,  Battle  Group  C4ISR  suites 

QoS  Engineering 

e.g..  Information  prioritization  based  on  Information  Needs 
Analysis 

Data  Architectures 

e.g.,  based  on  Information  Needs,  Production  /  Use  Logical 
Flow,  and  Synchronization  Analyses 

information  Standards  Design  and  Impiementation 

Comm.  Architectures  and  Network  Designs 

Network  Integration 

e.g.,  XTN-JDN-JPN,  NMCI/IT-21/MCTN 

Connectivity  and  Topology 

Robustness,  cost,  teleports,  commercial  SATCOM,  .. 

Standards  &  Services  Integration  &  Interoperability 

Translation/conversion,  acquisition,  flexibility  trade-offe 

Bandwidth  Management 

such  as  dynamic  provsioning  by  mission  criticality,  service 
requirements,  ... 

Functional  Interoperability 

Algorithm  and  logic  alternatives 

Procedural  Interoperability 

Training,  doctrine,  regulatory  dis-synchronizations  (Joint, 
coalition,  and  neutral) 

Coordinated  Evolution,  Migration,  and  Tech  insertion 

e.g.,  between  AEGIS  and  GCCS-M 

AV 

Operational  View  (OV) 

System  View  (SV) 

Tech 

View 

1  I  2 

U2|3|4|5|6|7 
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Figure  9-2.  Analytical  Selection  of  Architecture  Data  to  Develop  and  Collect 
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Common  Architecture  Framework 


In  the  DoD,  the  Arehitecture  Framework  Document  provides  a  common  architecture  framework 
that  defines  the  products,  their  information,  and  their  associated  CADM  data  elements,  as  shown 
in  Figure  9-3.  The  MCP  process  can  be  based  on  the  DoD  Architecture  Framework  and  uses  its 
constructs  to  conduct  the  analyses  described  in  the  previous  chapters  of  this  book. 


J^^srrjtTf  uaqmi,  ntpcfpximn  wb  i^iHm-rmp'-cocH 

[  I  HFommcMiEiiiwi 
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How  the  parts 
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represented  in 
a  CADM- 
based 
database 


Figure  9-3.  Moving  from  Templates  to  Components  to  Database  Elements  in  the  Architecture 
Framework  Document 


Common  Data  Structure 

As  previously  discussed,  CADM  is  the  common  data  structure  for  architecture  data.  With  the 
CADM,  it  is  possible  to  represent  which  operational  activities  are  performed  by  which 
operational  nodes;  what  information  is  required  (used  by)  which  operational  nodes;  how 
information  is  related  to  data;  what  system  functions  are  performed  by  what  systems;  the  current 
and  required  performance  characteristics  of  systems;  and  thousands  of  other  types  of  architecture 
information.  A  very  high-level  CADM  overview  graphic  is  shown  in  Figure  9-4.  The 
Department  of  the  Navy  (DON)  Integrated  Architecture  Database  (DIAD)  is  an  accurate  and 
complete  implementation  of  CADM. 
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Common  Data  Semantics 


While  a  common  framework  and  common  data  structure  are  important  for  data  consistency, 
creating  commonality  in  these  two  elements  alone  will  not  be  sufficient  for  the  development  of 
consistent  and  synchronizable  architecture  data.  The  common  structure  only  guarantees  common 
object  classes,  but  quantitative  analyses  of  the  types  described  in  this  book  require  common 
objects.  Common  objects  are  necessary  to  allow  analytical  threads  to  extend  across  the 
architecture  data  space  continuously.  Discontinuities  in  the  threads  (e.g.,  data  gaps  and 
inconsistencies)  can  seriously  degrade  the  analysis  results  and  in  many  cases  preclude  any  sort  of 
analysis.  They  can  create  false  assessments  of  interoperability,  cause  overestimation  of  capacity 
requirements,  and  mask  redundancies.  Taxonomies  are  one  method  for  addressing  problems 
created  by  data  semantics.  Taxonomies  can  be  used  to  support  MCP  analyses,  but  they  must 
possess  quality  features  like  those  identified  in  Table  9-5. 

The  DON  has  been  developing  taxonomies  to  support  MCP  analyses  as  well  as  other  DON 
processes  for  many  years.  For  example,  the  system  function  and  information  element  taxonomies 
can  be  traced  to  the  CNO  Functional  Allocation  study  conducted  in  1978.  The  taxonomies 
generated  by  DON  are  developed  and  managed  DON-wide  using  the  DIAD.  Through  the  years, 
many  lessons  have  been  learned  about  taxonomy  development,  and  consensus  was  reached 
regarding  relationships  between  node  definitions  and  categorizations.  These  definitions  and 
categorizations  are  summarized  in  Table  9-6  along  with  their  corresponding  DIAD  solutions. 
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Table  9-5 


Quality  Features  Necessary  for  Taxonomies  Used  to  Support  MCP  Analyses 


Quality 

Feature 

Sub- 

Feature 

Definition 

Completeness 

Scope 

Addresses  whether  the  taxonomy,  in  node  definitions  and 
structure,  covers  the  taxonomic  area  of  concern  for  the  enterprise 

Detail 

Addresses  whether  the  structure  is  sufficient  for  the  enterprise; 

Necessity 

Somewhat  the  opposite  of  completeness  in  that  it  addresses 
whether  or  not  the  taxonomy  at  hand  has  sufficient  significance 
of  structural  breadth  or  depth  to  warrant  enterprise-level 
visibility  and  management 

Structural 

Integrity 

Membership 

Addresses  the  logical  equivalence  of  the  subordinate  nodes  to  a 
node’s  description,  verifying  that  the  sum  of  the  descendants 
does  not  exceed  the  description  of  the  node  and,  conversely,  does 
not  leave  gaps  in  meeting  the  description  of  the  node;  this  feature 
is  essential  for  logical  implications  between  levels 

Balance 

Addresses  the  leveling  of  the  nodes,  so  that  nodes  at  the  same 
level  in  the  taxonomy  are  of  equal  significance  or  size 

Non¬ 

redundancy 

Addresses  requirement  that  a  taxonomy  support  membership  in 
one  and  only  one  node  (i.e.,  creates  no  ambiguity);  without  this 
feature,  like  objects  with  different  names  may  exist  undetected, 
thereby  sub-optimizing  analyses,  decisions,  and  designs 

Extensibility 
and  Generality 

Address  whether  the  taxonomy  has  been  defined  in  a  manner 
abstract  or  general  enough  to  enable  detailing  or  elaboration  by 
lower  echelon  agencies  and  departments  in  the  enterprise 

Well- 

Definedness 

Node 

Names 

Must  be  reasonably  unambiguous  and  intuitively  understandable 
terms 

Node 

Definitions 

Must  be  non-self-referential  and  should  provide  intuitive 
understanding  of  the  node  meaning 

Table  9-6 


Required  Taxonomy  Tool  Features  and  DIAD  Solutions 


Required  Feature 

DIAD  Solution 

Ability  to  “see”  the  taxonomy 

Use  tree,  hierarchy 

Ability  to  navigate  the  taxonomy 

Use  collapsible  and  expandable  branches 

Reconcilability 

Merge 

Restructurability 

Move  branches,  create  trial  branch  moves 

Relatability  to  local  taxonomies  or  multiple 
authoritative  sources 

Use  many-to-many  mapping 

Ability  to  match  up  like  concepts 

Find  by  various  criteria 
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Data  Synchronization 

MCP  architecture  data  can  be  developed  using  a  variety  of  tools.  The  Navy  Collaborative 
Engineering  Environment  (NCEE),  developed  within  the  ASN(RDA)  CHENG  Office,  provides 
the  capability  to  consolidate  an  MCP  data  set  within  its  object-oriented  data  repository.  The 
NCEE  objective  is  to  facilitate  the  transition  of  architecture  data  into  engineering  analysis  and 
M&S  tools  so  that  architecture  verification  and  assessment  can  be  tightly  coupled  with  other 
engineering  assessment  activities.  Ultimately,  this  MCP  architecture  data  set  would  reside  in  the 
CADM  database.  As  the  official  implementation  of  the  CADM  database,  DIAD  and  DoD 
Architecture  Repository  (DARS),  the  DoD-level,  CADM-compliant  architecture  database,  will 
work  in  conjunction  with  the  NCEE  to  synchronize  architecture  data  generated  by  various 
architecture  tools.  This  process  is  illustrated  in  the  overview  provided  in  Figure  9-5.  This 
configuration  will  address  architecture  data  synchronization  on  three  levels:  within  an 
architecture  project;  across  the  enterprise’s  other  core  process;  and  to  architectures  external  to 
the  enterprise. 


Within  an  architecture  project,  the  NCEE  provides  the  collaboration  capabilities  to  synchronize 
the  efforts  of  MCP  architects  working  in  different  locations  with  different,  non-fully-CADM- 
compliant  architecture  tools.  NCEE  includes  an  infrastructure  environment  that  facilitates  the 
sharing  and  manipulation  of  data  from  numerous  tools  and  data  repositories.  To  support  the  data 
exchange  and  data  synchronization  among  various  tools,  NCEE  provides  two  essential  features: 
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•  Tool  plug-in:  this  feature  in  the  NCEE  provides  the  capability  to  import  and  export  data  from 
an  individual  tool  or  database  into  Interchange,  the  NCEE’s  common  data  repository. 
Currently,  Interchange  has  several  plug-ins  to  engineering,  architecture,  and  M&S  tools 
including  DOORS,  CORE,  Excel,  and  ENVISON/ERGO.  Interchange’s  data  structure  is 
highly  flexible  so  that  it  can  be  extended  to  accommodate  additional  tools  and  to  enable  the 
forward  migration  of  existing  data.  The  basic  concept  for  sharing  data  among  architecture 
tools  is  to  implement  a  CADM  compliance  structure  within  Interchange  and  allow  the  tools  to 
exchange  data  with  each  other  or  with  the  DIAD  tool  through  the  import/export  mechanism. 
As  data  is  imported  into  Interchange,  relationships  can  be  established  among  the  data  sets  to 
support  complex  data  analyses.  Interchange  also  has  the  capability  to  preserve  information 
specific  to  the  individual  tool  so  the  tool  would  be  able  to  reconstruct  its  complete  model  with 
updated  information  from  other  tools.  Figure  9-6  illustrates  the  development  concept  for  tool 
plug-in. 

•  Database  configuration  management:  in  order  to  track  data  that  are  populated  by  various  tools 
and  users  from  multiple  sources.  Interchange  provides  a  sophisticated  configuration 
management  capability.  This  capability  includes  object-level  versioning  in  which  history 
objects  can  be  viewed,  purged,  deleted,  or  reverted  to  previous  versions;  configuration 
management  of  the  schema,  model  data,  and  tool/data  source  plug-ins;  user  access  control  that 
can  be  assigned  down  to  the  attribute  level  of  an  object;  and  a  query  builder  that  allows  users 
to  create,  execute,  and  store  queries  and  display  query  results  in  graphical  format. 


Figure  9-6.  Development  Concept  for  Tool  Plug-In 
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Although  the  NCEE  data  repository  eould  be  extended  to  support  additional  complex  data 
synchronization  issues,  it  is  logical  to  continue  utilizing  the  existing  DIAD  capability  and 
process  to  support  data  synchronization  across  enterprise  and  external  to  enterprise.  Across  core 
processes,  DIAD’s  standardized  CADM  data  is  available  for  interfacing  and  replication 
synchronization.  An  example  exists  in  the  Applications  Reduction  process  being  used  for  the 
Navy  and  Marine  Corps  Intranet  (NMCI)  project.  Although  NMCI  is  not  strictly  architectural, 
the  DIAD  Operational  Activity  and  System  Function  taxonomies  can  be  used  to  make 
synchronization  with  MCP  analyses  possible.  To  support  synchronization  beyond  the  DON,  the 
DIAD  uses  the  same  data  structure  as  DARS  (CADM),  which  facilitates  uploading  and 
downloading  from  DARS.  Through  the  CADM’s  key  block  allocation  scheme,  key  collisions 
should  not  occur. 

Capability  Evolution  Description  Data  Synchronization 

The  CED  is  a  new  set  of  data  that  is  not  currently  included  in  the  CADM  framework,  although 
efforts  to  include  this  data  in  the  CADM  are  ongoing  at  the  time  of  the  writing  of  this  book. 
Collecting  CED  data  without  an  automated  capability  is  a  complicated  process  because  there  are 
many  architecture  data  elements  involved,  and  the  derived  data  is  based  upon  dependencies 
among  those  data  elements.  In  support  of  PR-05  MCP  data  generation,  the  ASN(RDA)  CHENG 
architecture  team  strived  to  compile  CED  data  using  a  set  of  templates  shown  in  Figure  9-7  along 
with  additional  data  existing  in  the  CADM  framework.  The  objective  of  the  template  is  to  enable 
collection  of  data  that  could  be  used  to  determine  how  well  a  group  of  systems  and  platforms  (or 
an  FoS)  contributes  to  a  set  of  mission  capability  objectives  within  a  specific  timeframe.  If  this 
data  is  collected  for  many  timeframes,  the  collected  data  will  indicate  how  the  capabilities  of  the 
identified  collection  of  systems  evolved  over  time. 
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Figure  9-7.  CED  Template 
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Mission  capability  objectives  can  vary  depending  upon  the  mission  of  interest.  If  capability 
objectives  are  identified  in  conjunction  with  the  associated  metrics  related  to  the  collection  of 
data  for  platforms  and  systems,  then  (technically,  at  least)  algorithms  can  be  determined  to 
calculate  how  well  these  systems  and  platforms  contribute  to  capability  objectives.  In  general, 
however,  the  associated  metrics  often  depend  on  analysis  and/or  M&S  results,  so  it  is  not 
feasible  at  this  time  to  automate  the  generation  of  capability  objective  inputs.  Instead,  the  CED 
template  can  be  used  by  the  domain  expert  to  provide  input  of  assessment  results.  For  example, 
in  Figure  9-7,  the  Strategic  Strike  Mission  Component  is  found  under  the  Strike  MCP  within  the 
Sea  Strike  Pillar.  Under  the  “PLATFORM/SYSTEM  NAME”  column  is  the  list  of  the  systems 
and  platforms  that  would  contribute  capabilities  to  this  mission  component  area.  Within  each 
timeframe  (measured  in  quarters  within  a  fiscal  year),  the  domain  expert  could  select  from  the 
following  assessments  of  system  and  platform  status: 

•  O:  On-line 

•  OM:  On-line  with  Minimal  Capability 

•  R:  Retired 

•  EC:  Integration  Enhances  Capability 

•  DC:  Delayed  Capability  Integration 

•  MC:  Minimal  Capability  Integration 

The  domain  expert  would  also  select  how  well  (Partially  Achieve,  Achieve,  Not  Achieve)  the 
FoSs  and  platforms  contribute  to  the  listed  capability  objectives  (Lethality,  Coverage, 
Timeliness,  Persistence,  and  Survivability). 

Figure  9-8  on  the  following  page  provides  an  entity-level  CADM  sub  view  for  CED  data.  The 
model  shows  that  mission  capability  depends  upon  a  variety  of  factors,  including  systems, 
physical  nodes,  system  functions,  system  migrations/evolutions/P3I,  platform  migration/ 
evolution/P3I,  performance,  technology,  interfaces,  system  dependencies,  and  system  status. 
When  these  CED  data  elements  are  fully  identified,  the  data  can  be  transitioned  to  project 
scheduling  tools  for  further  GANNT,  PERT,  and  other  standard  analyses.  CED  data  is  also  ideal 
for  various  multi-attribute  analyses.  Another  prototype  capability  under  consideration  is  the 
ability  to  generate  a  CED  graphical  view  automatically  based  on  the  collected  data. 

Summary 

In  order  for  architecture  assessments  supporting  MCP  analyses  results  to  be  accurate,  the  data 
used  to  conduct  the  analysis  must  have  integrity.  MCP  analysis  results  will  be  most  affected  by 
two  principal  data  integrity  factors:  the  architecture  data  values  and  the  consistency  among 
architecture  data  values  and  with  data  values  within  and  beyond  a  single  service  (e.g.,  the  DON). 
To  achieve  architecture  data  management  in  terms  of  synchronization  and  consistency,  the 
architecture  project  team  must  incorporate,  at  a  minimum,  the  principles  embodied  in  five  data 
and  architecture  guidelines:  data  development  plan;  common  architecture  framework;  common 
data  structure;  common  data  semantics;  and  data  synchronization.  Data  synchronization  is  a  key 
issue  since  the  DoD  develops  mission  architecture  data  using  a  variety  of  tools.  The  Navy 
currently  plans  to  use  CADM  in  conjunction  with  DIAD  and  NCEE  to  synchronize  architecture 
data  generated  by  various  architecture  tools.  Efforts  to  include  CED  data  in  the  CADM 
framework  are  also  ongoing  at  the  time  of  the  writing  of  this  book. 
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Figure  9-8.  Proposed  CADM  Entity-Level  Diagram  for  CED 
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LIST  OF  ACRONYMS 

ACTD 

Advanced  Concept  Technology  Demonstration 

AFATDS 

Army  Field  Artillery  Tactical  Data  System 

ALAM 

Advanced  Land  Attack  Missile 

AO 

Area  of  Operations 

ASAS 

All  Source  Analysis  System 

ASD 

Assistant  Secretary  of  Defense 

ASN 

Assistant  Secretary  for  the  Navy 

ASW 

Anti-Submarine  Warfare 

AT&L 

Acquisition,  Technology,  and  Logistics 

ATACMS 

Advanced  Tactical  Missile  System 

ATO 

Air  Tasking  Order 

BFA 

Battle  Functional  Area 

BMDS 

Ballistic  Missile  Defense  System 

C2 

Command  and  Control 

C4I 

Command,  Control,  Communications,  Computers,  and  Intelligence 

C4ISP 

Command,  Control,  Communications,  Computers,  and  Intelligence 
Support  Plan 

C4ISR 

Command,  Control,  Communications,  Computers,  Intelligence, 
Surveillance,  and  Reconnaissance 

CADM 

Core  Architecture  Data  Model 

CDL 

Common  Data  Link 

CEC 

Cooperative  Engagement  Capability 

CED 

Capability  Evolution  Description 
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CFO 

Communicate  Force  Orders 

CGP 

Common  Ground  Picture 

CHENG 

Chief  Engineer 

CIAP 

Coalition  Integrated  Air  Picture 

CISA 

Command  Information  Superiority  Architectures 

CJTF 

Commander,  Joint  Task  Force 

CNO 

Chief  of  Naval  Operations 

CO 

Communicate  Order 

COA 

Course  of  Action 

CONOPS 

Concept  of  Operations 

COTS 

Commercial  Off-The-Shelf 

CRD 

Capstone  Requirements  Document 

CS 

Communicate  Status 

CSD 

Communicate  Sense  Data 

CV 

Capability  View 

CV-6 

Capability  Evolution  Description 

DARS 

Department  of  Defense  (DoD)  Architecture  Repository 

DIAD 

Department  of  the  Navy  Integrated  Architecture  Database 

DII  COE 

Defense  Information  Infrastructure  Common  Operating  Environment 

DoD 

Department  of  Defense 

DODAF 

DoD  Architecture  Framework 

DON 

Department  of  the  Navy 
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DOTMLPF 

Doctrine,  Organization,  Training,  Materiel,  Leadership,  Personnel,  and 
Facilities 

DSC 

Decision  Support  Center 

ECM 

Electromagnetic  Countermeasures 

EE 

Engagement  Execution 

EMI 

Electromagnetic  Interference 

ERGM 

Extended  Range  Guided  Munition 

FBE-I 

Fleet  Battle  Experiment  -  India 

FP 

Force  Positioning 

FoS 

Family  of  Systems 

GCCS 

Global  Command  and  Control  System 

GIG 

Global  Information  Grid 

GOTS 

Government  Off-The-Shelf 

GSM 

Ground  Station  Module 

HA/DR 

Flumanitarian  Assistanee/Disaster  Relief 

ICOMs 

Inputs,  Controls,  Outputs,  and  Mechanisms 

IE 

Information  Element 

IEEE 

Institute  of  Electrical  and  Electronics  Engineers 

lER 

Information  Exehange  Requirement 

IKA 

Information  and  Knowledge  Advantage 

IMINT 

Imagery  Intelligenee 

IPT 

Integrated  Program  Team 

IR 

Infrared 

ISPP 

Integrated  Sponsor  Planned  Program 
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ISR 

Intelligence,  Surveillance,  and  Reconnaissance 

JCC(X) 

Joint  Maritime  Command  and  Control  Capability  (Experimental) 

JCMOTFC 

Joint  Civil  Military  Operations  Task  Force  Commander 

JCS 

Joint  Chiefs  of  Staff 

JFACC 

Joint  Force  Air  Component  Commander 

JFC 

Joint  Force  Commander 

JFLCC 

Joint  Force  Land  Component  Commander 

JFMCC 

Joint  Force  Marine  Component  Commander 

JFSOCC 

Joint  Force  Special  Operations  Component  Commander 

JITC 

Joint  Interoperability  Test  Command 

JMA 

Joint  Mission  Area 

JMAAT 

Joint  Mission  Area  Analysis  Tool 

JMETL 

Joint  Mission  Essential  Task  List 

JPOTFC 

Joint  Psychological  Operations  Task  Force  Commander 

JRCOA 

Joint  Task  Force  Representative  C4ISR  Operational  Architecture 

JROC 

Joint  Requirements  Oversight  Council 

JTA 

Joint  Technical  Architecture 

JTF 

Joint  Task  Force 

JWAR 

Joint  Warfare  Architecture 

KIP 

Key  Interface  Point 

KPP 

Key  Performance  Parameter 

LSAM 

Land  Attack  Standard  Missile 

LPTF 

Littoral  Penetration  Task  Force 
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M&S 

Modeling  and  Simulation 

MCP 

Mission  Capability  Package 

MNS 

Mission  Needs  Statement 

MOE 

Measure  of  Effectiveness 

MOP 

Measure  of  Performance 

MS 

Multi  Sensor 

MTW 

Major  Theatre  War 

NAVSEA 

Naval  Sea  Systems  Command 

NCEE 

Naval  Collaborative  Engineering  Environment 

NCO 

Network  Centric  Operations 

NCTSI 

Naval  Command  for  Testing  System  Interoperability 

NOW 

Network  Centric  Warfare 

NETWARS 

Network  Warfare  Simulation 

NGO 

Non-Government  Organization 

Nil 

Network  Integration  and  Interoperability 

NMCI 

Navy  and  Marine  Corps  Intranet 

NRO  TPED 

National  Reconnaissance  Office  Targeting,  Processing,  Exploitation,  and 
Dissemination 

NTM 

National  Technical  Means 

NTOA 

Naval  Targeting  Operational  Architecture 

NWDC 

Naval  Warfare  Development  Center 

OGO 

Other  Government  Organization 

ORD 

Operational  Requirements  Document 
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OSD 

Office  of  the  Secretary  of  Defense 

OASD 

Office  of  the  Assistant  Secretary  of  Defense 

OODA 

Observe,  Orient,  Decide,  Act 

OSI 

Open  System  Interface 

OUSD 

Office  of  the  Undersecretary  of  Defense 

OV 

Operational  View 

OV-1 

High-Level  Operational  Concept  Graphic 

OV-2 

Operational  Node  Connectivity  Description 

OV-3 

Operational  Information  Exchange  Matrix 

OV-4 

Organizational  Relationships  Chart 

OV-5 

Operational  Activity  Model 

OV-6c 

Operational  Event/Trace  Description 

PACOM 

Pacific  Command 

PGM 

Precision  Guided  Munitions 

PNT 

Precision  Navigation  and  Timing 

POM 

Program  Objective  Memorandum 

P-Spec 

Preliminary  Specification 

PVO 

Private  Volunteer  Organization 

RDA 

Research,  Development,  and  Acquisition 

RF 

Radio  Frequency 

SA 

Situational  Assessment 

SAM 

Strategic  Air  Missile 

SATCOM 

Satellite  Communication 
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SIAP 

Single  Integrated  Air  Pieture 

SIGINT 

Signals  Intelligence 

SOF 

Special  Operations  Forces 

SoS 

System  of  Systems 

SPAWAR 

Space  and  Naval  Warfare  Systems  Command 

ss 

Single  Sensor 

sv 

System  View 

SV-3 

Systems-to-Systems  Matrix 

SV-3a 

Systems  to  Systems  Functions 

SV-3b 

Operational  Activities  to  Systems  Traceabilty  Matrix 

SV-3c 

Systems^  Matrix 

SV-4 

Systems  Functionality  Description 

SV-4a 

High-Level  Systems  Functions  List 

SV-4b 

Systems  Functional  View 

SV-4c 

Logical  Interface  View 

SV-5 

Operational  Activity  to  Systems  Function  Traceability  Matrix 

SV-6 

System  Data  Exchange  Matrix 

SV-8 

System  Evolution  Description 

SV-9 

System  Technology  Forecast 

TA 

Technical  Architecture 

TACAIR 

Tactical  Air 

TAMD 

Theater  Air  Missile  Defense 

TBM 

Theater  Ballistic  Missile 
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TCPED 

Tasking,  Collection,  Processing,  Exploitation,  and  Dissemination 

TP-4 

Technical  Panel  Four 

TRIXS 

Tactical  Reconnaissance  Intelligence  Exchange  System 

TST 

Time  Sensitive  Targeting 

TTCP 

The  Technical  Cooperation  Program 

TTLAM 

Tactical  Tomahawk  Land  Attack  Missile 

TTPs 

Tactics,  Techniques,  and  Procedures 

TV 

Technical  View 

TV-1 

Technical  Standards  Profde 

TV-2 

Standards  Technology  Forecast 

UAV 

Unmanned  Air  Vehicle 

UJTL 

Universal  Joint  Task  List 

USJFCOM 

U.S.  Joint  Forces  Command 

USMTF 

U.S.  Message  Text  Format 

WTP 

Weapon  Target  Pairing 
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